Import location (Library Location) Does not change when moving old locations to a disk With Space

[Paelsmoessan]

Is there an existing issue for this?

• I have searched the existing open and closed issues

Current Behavior

I tried adding it as a feature request but it seems we have some triagers hot on the cancel button.
First of I have been using Radarr for a decade with only praises to give, I have no need for support.
One thing that has bugged me through the years though is that my storage disks some times run out of space. Well great I can add more storage, and I have a lot.
Problem occurs when I have old Movies on a disk that is now full and Radarr wants to upgrade it -Which is GREAT- I want upgrades.
However when I have movies downloaded waiting to import and the library disk is full I move the existing location via Radarr to a disk that has more space. The issue is that the already downloaded and waiting files does not update the new location property which means that if I now have space on that original location Radarr will import it to the old location giving me duplicates. If however I still do not have space Radarr will keep the files waiting to import forever. Since the Import location only is a property this should be able to be updated and then executed when the next scheduled task runs.

Expected Behavior

Update the Import Destination Location for waiting files.

Steps To Reproduce

Fill a disk and try importing a file that is too large. Move the original to make space and see what happens.

Environment

- OS: Windows
- Radarr: Nightly
- Docker Install: No
- Using Reverse Proxy: Yes
- Browser: Brave
- Database: Huh?

What branch are you running?

Nightly

Trace Logs? Not Optional

Trace Logs have been provided as applicable. Reports will be closed if the required logs are not provided.

• I have read and followed the steps in the wiki link above and provided the required trace logs - the logs contain trace - that are relevant and show this issue.

[bakerboy448]

1. not a bug. This is expected. Once a movie is in manual import stuck status it is the human's problem to resolve. If the issue is the new path is not being respected for manual imports of stuck items then a proper bug report would need to be completed and the OP provided information does not reflect that.
2. invalid bug report
   2b) logs not provided
   2c) OP has lied about following the wiki and providing logs
   2d) "nightly" is not a valid radarr version
   2e) "Huh?" Is not a valid radarr database

[Paelsmoessan]

2024-04-26 19:24:11.3|Debug|AlreadyImportedSpecification|Skipping already imported check for movie without file
2024-04-26 19:24:11.3|Warn|FreeSpaceSpecification|Not enough free space (7045451776) to import: D:\Completed\Movies\Young.Guns.II.1990.1080p.BluRay.X264-AMIABLE\4a304925fb7b48b49996d79eaf5dd885.mkv (11736425605)
2024-04-26 19:24:11.3|Debug|VideoFileInfoReader|Getting media info from D:\Completed\Movies\Young.Guns.II.1990.1080p.BluRay.X264-AMIABLE\4a304925fb7b48b49996d79eaf5dd885.mkv
2024-04-26 19:24:11.3|Debug|DetectSample|[D:\Completed\Movies\Young.Guns.II.1990.1080p.BluRay.X264-AMIABLE\4a304925fb7b48b49996d79eaf5dd885.mkv] does not appear to be a sample. Runtime 01:44:04.2380000 seconds is more than minimum of 600 seconds
2024-04-26 19:24:11.3|Debug|ImportDecisionMaker|File rejected for the following reasons: [Permanent] Not enough free space
2024-04-26 19:24:11.3|Debug|ImportApprovedMovie|Decisions: 1
2024-04-26 19:24:11.3|Debug|CompletedDownloadService|Not all movies have been imported for Young.Guns.II.1990.1080p.BluRay.X264-AMIABLE
2024-04-26 19:24:11.3|Debug|Radarr.Http.Authentication.ApiKeyAuthenticationHandler|AuthenticationScheme: API was successfully authenticated.
2024-04-26 19:24:11.3|Debug|Radarr.Http.Authentication.ApiKeyAuthenticationHandler|AuthenticationScheme: API was successfully authenticated.
2024-04-26 19:24:11.3|Debug|Api|[GET] /api/v3/queue/details: 200.OK (1 ms)
2024-04-26 19:24:11.3|Debug|Api|[GET] /api/v3/queue?page=1&pageSize=20&sortDirection=ascending&sortKey=timeleft&includeUnknownMovieItems=true: 200.OK (1 ms)
2024-04-26 19:24:11.3|Debug|Radarr.Http.Authentication.ApiKeyAuthenticationHandler|AuthenticationScheme: API was successfully authenticated.
2024-04-26 19:24:11.3|Debug|Api|[GET] /api/v3/command: 200.OK (1 ms)
2024-04-26 19:25:11.2|Debug|Radarr.Http.Authentication.ApiKeyAuthenticationHandler|AuthenticationScheme: API was successfully authenticated.
2024-04-26 19:25:11.2|Debug|Api|[GET] /api/v3/command: 200.OK (2 ms)
2024-04-26 19:25:21.8|Debug|Radarr.Http.Authentication.ApiKeyAuthenticationHandler|AuthenticationScheme: API was successfully authenticated.
2024-04-26 19:25:21.8|Debug|Radarr.Http.Authentication.ApiKeyAuthenticationHandler|AuthenticationScheme: API was successfully authenticated.
2024-04-26 19:25:21.8|Debug|Api|[GET] /api/v3/health: 200.OK (1 ms)
2024-04-26 19:25:21.8|Debug|Radarr.Http.Authentication.ApiKeyAuthenticationHandler|AuthenticationScheme: API was successfully authenticated.
2024-04-26 19:25:21.8|Debug|Api|[GET] /api/v3/system/status: 200.OK (2 ms)
2024-04-26 19:25:22.0|Debug|Api|[GET] /api/v3/diskspace: 200.OK (190 ms)
2024-04-26 19:25:33.1|Debug|Radarr.Http.Authentication.ApiKeyAuthenticationHandler|AuthenticationScheme: API was successfully authenticated.
2024-04-26 19:25:33.2|Debug|Api|[GET] /api/v3/log/file: 200.OK (34 ms)

Database
Sqlite 3.36.0

You can recreate this behavior in 5 minutes, it's been the same for as long as I have used Radarr (10 years or more) and you do not need my database nor my logs for this.

I am not trying to be a nuisance, I dabble a bit in programming myself. I am trying to be helpful.

[bakerboy448]

• trace are not debug
• pasting the logs into github issue not even in a codeblock are not helpful

[Paelsmoessan]

You do not need debug logs since this is not a bug but a feature that hasn't been dealt with for 10 years.

[bakerboy448]

I don't think your in any position to state what is or is not required....however if this a feature request then it should be closed as an invalid bug report. if it is a bug report, then the required trace logs were failed to be provided and OP LIED about providing so....this could be closed as invalid again.

[bakerboy448]

Triage from convo with B
TrackedDownloadService doesn't clear the cache on moved movies event. event is bulk, so need to figure out to best handle.