starred/Radarr

Fork 0

mirror of https://github.com/Radarr/Radarr.git synced 2026-03-02 22:57:34 -05:00

Batch root folder change with file move updates the movie location before the files are moved #5527

New issue

Open

opened 2026-02-19 22:59:39 -05:00 by deekerman · 9 comments

deekerman commented

2026-02-19 22:59:39 -05:00

Owner

Originally created by @mathieugfortin on GitHub (Feb 2, 2021).

When doing a batch movie root folder change, the movie root folder is changed immediately but the file move is only queued, not done.

If the queue is long, there is a time where the UI thinks the movie is in path /new while the file is in path /old. During that time, refreshes cause problems. More importantly, if radarr crashes (caused by a server problem in my case) you end up with a bunch of movies that exist in the old path but that radarr can't find anymore.
The DB update should happen after the file move is done.

To Reproduce

Go to Movies -> Movie Editor -> select all (the selection must be large enough to cause significant move time)
Click on root folder, select a different root folder
Select "Yes, move the files"
Go to one of the moved movies
Click on Refresh & Scan

Expected behavior
Movie path should point to the old path until the files are finished copying.

Platform Information (please complete the following information):

OS:
Docker: Yes
Mono or .NET Version (System -> Status): .NET Yes (5.0.2)
Browser and Version (Only needed for UI issues): Firefox 85.0
Radarr Version: 3.1.0.4529-ls12 by linuxserver.io
Radarr Branch: not sure, I use linuxserver/radarr:nightly

AB#680

Originally created by @mathieugfortin on GitHub (Feb 2, 2021). When doing a batch movie root folder change, the movie root folder is changed immediately but the file move is only queued, not done. If the queue is long, there is a time where the UI thinks the movie is in path */new* while the file is in path */old*. During that time, refreshes cause problems. More importantly, if radarr crashes (caused by a server problem in my case) you end up with a bunch of movies that exist in the old path but that radarr can't find anymore. The DB update should happen after the file move is done. **To Reproduce** 1. Go to Movies -> Movie Editor -> select all (the selection must be large enough to cause significant move time) 2. Click on root folder, select a different root folder 3. Select "Yes, move the files" 4. Go to one of the moved movies 5. Click on Refresh & Scan **Expected behavior** Movie path should point to the old path until the files are finished copying. **Platform Information (please complete the following information):** - OS:  - Docker: Yes - Mono or .NET Version (System -> Status): .NET Yes (5.0.2) - Browser and Version (Only needed for UI issues): Firefox 85.0 - Radarr Version: 3.1.0.4529-ls12 by linuxserver.io - Radarr Branch: not sure, I use linuxserver/radarr:nightly [AB#680](https://dev.azure.com/Servarr/7ab38f4e-5a57-4d70-84f4-94dd9bc5d6df/_workitems/edit/680)

deekerman added the

labels

2026-02-19 22:59:39 -05:00

deekerman commented

2026-02-19 22:59:40 -05:00

Author

Owner

@stale[bot] commented on GitHub (Jun 25, 2021):

This issue has been automatically marked as stale because it has not had recent activity. Please verify that this is still an issue with the latest version of Radarr and report back. Otherwise this issue will be closed.

@stale[bot] commented on GitHub (Jun 25, 2021): This issue has been automatically marked as stale because it has not had recent activity. Please verify that this is still an issue with the latest version of Radarr and report back. Otherwise this issue will be closed.

deekerman commented

2026-02-19 22:59:40 -05:00

Author

Owner

@ghost commented on GitHub (Aug 12, 2021):

This should be done one file at a time. eg

Copy a file
Verify its copied (if failed, revert with error or retry)
Repeat 1 & 2 until ALL the contents of the folder are successfully copied (revert back if failed with log error and/or retry)
Once a folder has successfully copied over to the new location, then delete the old folder
Update the DB with the new move details.
Repeat with the next item (movie, folder, etc.)..

It should NOT be done as 1) Move all the files 2) Update the DB, since it will break again if interrupted!

Right now, if anything gets interrupted with bulk moves (20+), folders disappear from the hard drive and cannot be found either in the old and new locations, yet the DB has them listed as "Downloaded" in the 'new' location but no h/d folders - Radarr is deleting the Movie from the h/d from the old location and not moving them anyhow.

@ghost commented on GitHub (Aug 12, 2021): This should be done one file at a time. eg 1) Copy a file 2) Verify its copied (if failed, revert with error or retry) 3) Repeat 1 & 2 until ALL the contents of the folder are successfully copied (revert back if failed with log error and/or retry) 4) Once a folder has successfully copied over to the new location, then delete the old folder 5) Update the DB with the new move details. 6) Repeat with the next item (movie, folder, etc.).. It should NOT be done as 1) Move all the files 2) Update the DB, since it will break again if interrupted! Right now, if anything gets interrupted with bulk moves (20+), folders disappear from the hard drive and cannot be found either in the old and new locations, yet the DB has them listed as "Downloaded" in the 'new' location but no h/d folders - Radarr is deleting the Movie from the h/d from the old location and not moving them anyhow.

deekerman commented

2026-02-19 22:59:40 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Aug 12, 2021):

This should be done one file at a time. eg

Copy a file

Verify its copied (if failed, revert with error or retry)

Repeat 1 & 2 until ALL the contents of the folder are successfully copied (revert back if failed with log error and/or retry)

Once a folder has successfully copied over to the new location, then delete the old folder

Update the DB with the new move details.

Repeat with the next item (movie, folder, etc.)..

It should NOT be done as 1) Move all the files 2) Update the DB, since it will break again if interrupted!

Agree; this is an issue inherited from Sonarr and the concept of what you suggest is reasonable.

Right now, if anything gets interrupted with bulk moves (20+), folders disappear from the hard drive and cannot be found either in the old and new locations, yet the DB has them listed as "Downloaded" in the 'new' location but no h/d folders - Radarr is deleting the Movie from the h/d from the old location and not moving them anyhow.

Trace logs? I could see this if one is shutting down the system literally mid copy, but don't think it's something radarr would be doing given every file move is a copy then delete or atomic move

@bakerboy448 commented on GitHub (Aug 12, 2021): > This should be done one file at a time. eg > > 1. Copy a file > 2. Verify its copied (if failed, revert with error or retry) > 3. Repeat 1 & 2 until ALL the contents of the folder are successfully copied (revert back if failed with log error and/or retry) > 4. Once a folder has successfully copied over to the new location, then delete the old folder > 5. Update the DB with the new move details. > 6. Repeat with the next item (movie, folder, etc.).. > > It should NOT be done as 1) Move all the files 2) Update the DB, since it will break again if interrupted! > Agree; this is an issue inherited from Sonarr and the concept of what you suggest is reasonable. > Right now, if anything gets interrupted with bulk moves (20+), folders disappear from the hard drive and cannot be found either in the old and new locations, yet the DB has them listed as "Downloaded" in the 'new' location but no h/d folders - Radarr is deleting the Movie from the h/d from the old location and not moving them anyhow. Trace logs? I could see this if one is shutting down the system literally mid copy, but don't think it's something radarr would be doing given every file move is a copy then delete or atomic move

deekerman commented

2026-02-19 22:59:40 -05:00

Author

Owner

@stale[bot] commented on GitHub (Jan 8, 2022):

@stale[bot] commented on GitHub (Jan 8, 2022): This issue has been automatically marked as stale because it has not had recent activity. Please verify that this is still an issue with the latest version of Radarr and report back. Otherwise this issue will be closed.

deekerman commented

2026-02-19 22:59:40 -05:00

Author

Owner

@OmniTitan commented on GitHub (Nov 28, 2023):

This remaing an issue and is occurring on my instance.

@OmniTitan commented on GitHub (Nov 28, 2023): This remaing an issue and is occurring on my instance.

deekerman commented

2026-02-19 22:59:40 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Nov 28, 2023):

This remaing an issue and is occurring on my instance.

Version numbers are required/useful when saying issues still occur

@bakerboy448 commented on GitHub (Nov 28, 2023): > This remaing an issue and is occurring on my instance. Version numbers are required/useful when saying issues still occur

deekerman commented

2026-02-19 22:59:40 -05:00

Author

Owner

@Sternpaul commented on GitHub (Jan 25, 2025):

Still an issue in 5.17.2.9580, this is very annoying when having a long queue, especially when one drive is full. Please fix asap

@Sternpaul commented on GitHub (Jan 25, 2025): Still an issue in 5.17.2.9580, this is very annoying when having a long queue, especially when one drive is full. Please fix asap

deekerman commented

2026-02-19 22:59:40 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Jan 25, 2025):

Please fix asap

The primary development team is engaged in over five applications, including Lidarr, Prowlarr, Radarr, Readarr, Whisparr, and Sonarr. Currently, there is approximately one active developer contributing to these projects, with none of the contributors working on them full-time. Additionally, all members involved, whether in development or support roles, are volunteers and do not receive compensation for their contributions. Each team member balances their commitments alongside full-time jobs, family responsibilities, and other personal obligations.

As a result, the list of tasks to be completed across these projects, along with the various backends and modules, is extensive, while the available time for addressing these tasks is limited.

@bakerboy448 commented on GitHub (Jan 25, 2025): > Please fix asap The primary development team is engaged in over five applications, including Lidarr, Prowlarr, Radarr, Readarr, Whisparr, and Sonarr. Currently, there is approximately one active developer contributing to these projects, with none of the contributors working on them full-time. Additionally, all members involved, whether in development or support roles, are volunteers and do not receive compensation for their contributions. Each team member balances their commitments alongside full-time jobs, family responsibilities, and other personal obligations. As a result, the list of tasks to be completed across these projects, along with the various backends and modules, is extensive, while the available time for addressing these tasks is limited.

deekerman commented

2026-02-19 22:59:40 -05:00

Author

Owner

@Sternpaul commented on GitHub (Jan 25, 2025):

This problem probably exists over the whole range of arrs and is not Radarr specific. I guess 4 years after the issue has been raised the first time, one could write "asap"...

@Sternpaul commented on GitHub (Jan 25, 2025): This problem probably exists over the whole range of arrs and is not Radarr specific. I guess 4 years after the issue has been raised the first time, one could write "asap"...