500 error on manual import for first-time movies (filterExistingFiles=true)

[romquenin]

Environment: Radarr 6.3.0.10514, servarr-auto-import 0.1.0 (Docker, dry-run)

The tool detects a blocked import correctly but fails to complete it for a movie that has never been imported before. Radarr returns a 500 error and the tool logs "no files returned".

Tool log:

[INFO] Radarr: processing 'VOYAGE.A.TOKYO.RESTAURATION.4K.VOSTFR.1080P.BLURAY.HEVC.FLAC-AZAZE.mkv'
[ERROR] HTTP 500 GET /api/v3/manualimport?folder=...&movieId=3146&filterExistingFiles=true
[WARNING] Radarr: no files returned for 'VOYAGE.A.TOKYO.RESTAURATION.4K.VOSTFR.1080P.BLURAY.HEVC.FLAC-AZAZE.mkv'

Radarr's error:

DirectoryNotFoundException: Could not find a part of the path '/movies/MOVIES/Tokyo Story (1953)'
  at ManualImportService.GetMediaFiles(Int32 movieId)

Likely cause: /movies/MOVIES/Tokyo Story (1953) is the movie's library folder, not the download folder. Since this is a first-time import, that folder doesn't exist yet — Radarr only creates it after a successful import. Passing filterExistingFiles=true together with movieId seems to make Radarr scan the (nonexistent) library folder instead of the download folder, causing the crash.

Suggested fix: Don't send filterExistingFiles=true for first-time imports, or retry with filterExistingFiles=false if the first call returns a 500.

To reproduce: Have a movie in Radarr with no file yet, let it get grabbed via ID-based matching (e.g. through Prowlarr), then let servarr-auto-import try to import it once downloaded.

[romquenin]

Update: I dug into this further and found the root cause(s) — turned out to be more than just the filterExistingFiles issue. Sharing a working patch (attached: auto_import.py) in case it's useful, or as a reference for a proper fix.

Root causes found

1. Missing downloadId in the /manualimport GET request. Looking at Radarr's ManualImportController:

   if (movieId.HasValue && downloadId.IsNullOrWhiteSpace())
   {
       return _manualImportService.GetMediaFiles(movieId.Value)...  // scans the movie's LIBRARY folder
   }
   return _manualImportService.GetMediaFiles(folder, downloadId, movieId, filterExistingFiles)...  // scans the actual DOWNLOAD folder

   Without downloadId, Radarr scans the movie's library folder instead of the download folder. For first-time imports that library folder doesn't exist yet, which throws (see System.IO.DirectoryNotFoundException: Could not find a part of the path Radarr/Radarr#10931, marked "Won't Fix"). Adding downloadId to the query routes to the correct code path.

2. The rejection filter was too strict. The tool skipped any item with rejections, but "Unable to parse file" is exactly the rejection that causes these ID-matched blocks in the first place. Since the movie/series/artist is already resolved via ID at that point, this specific rejection is safe to ignore. Other rejection reasons still block the import as before.

3. Missing downloadId, folderName, releaseGroup in the POST payload. ManualImportFile (server-side) has these fields, but the tool's POST body only sent path, movieId, quality, languages, indexerFlags. Without downloadId specifically, Radarr can't properly associate the import with the tracked download.

4. No verification that the command actually succeeded. POST /api/v3/command only queues the command — Radarr processes ManualImport asynchronously. The tool treated "got a response" as "import succeeded," which is a false positive: the command can still fail afterwards (permissions, disk errors, etc.) with no indication at the point of the POST. The patch polls GET /api/v3/command/{id} until the command reaches completed/failed, with a generous timeout for large files.

Note: even Radarr's own "Manually imported N files" message on command completion isn't fully reliable — it just reflects imported.Count (a list length) regardless of whether each individual file import actually succeeded. The only way to get the real failure reason is Radarr's own history/logs, not the command response.

Patch

Attached auto_import.py includes all of the above for Sonarr, Radarr, and Lidarr. Tested end-to-end against Radarr 6.3.0.10514 — confirmed a previously-blocked first-time import now completes correctly (file moved, queue cleared).

Happy to open this as a PR if that's easier to review than a dropped-in file.

auto_import.py