Sonarr/RDTClient Pipeline Fixes: FinishedAction, Retry Counts, and Queue Cleanup
Why: After the split-RDTClient migration, downloads were completing on TorBox and landing in the temp directory but never being imported by Sonarr — and the queue was accumulating stale error entries even for successful downloads.
Root-cause analysis of the media pipeline revealed several interacting bugs. The biggest: FinishedAction = 1 in both RDTClient instances was set to delete completed torrents from the queue immediately upon completion (with zero delay). Sonarr polls RDTClient periodically — by the time it polled, the record was gone. Sonarr never saw the completion, assumed the download had failed, grabbed a lower-quality replacement, and left the original file sitting in the temp directory indefinitely. This also triggered an upgrade loop where Sonarr would delete the existing library file expecting a better one to arrive, then lose track of the replacement download too.
1. FinishedAction: 1 → 0 (keep in queue until Sonarr imports)
Changed Integrations:Default:FinishedAction, Provider:Default:FinishedAction, and Gui:Default:FinishedAction from 1 (delete immediately) to 0 (keep in queue) in both /home/rdtclient/db/rdtclient.db and /home/plex/rdtclient-movies/db/rdtclient.db. With this set, completed downloads persist in RDTClient's queue until Sonarr polls, imports, and removes them — the intended behaviour for any qBittorrent-compatible client.
2. Retry counts tuned
Increased Integrations:Default:TorrentRetryAttempts and Provider:Default:TorrentRetryAttempts from 1 to 3 in both instances. One retry was too few to survive transient TorBox DATABASE_ERROR responses without permanently abandoning the torrent. Also increased DownloadRetryAttempts to 5. Kept at 3 (not 5) for the torrent submission attempts to balance reliability against wait time — each failed attempt adds several seconds to Sonarr's blocking WaitForTorrent call.
3. rdtclient-movies MappedPath fixed
The fresh-install default for DownloadClient:MappedPath in rdtclient-movies was C:\Downloads (a Windows path). Changed to /data/downloads to match the actual container download path, so Radarr's remote path mapping resolves correctly.
4. Series and movie path migration
After the volume remapping in the split-RDTClient setup, all 247 Sonarr series still referenced /tv/Show Name and all 7 Radarr movies referenced /movies/Movie Name. Updated via direct SQLite on stopped containers:
- Sonarr:
UPDATE Series SET Path = '/data/TV' || SUBSTR(Path, 4) WHERE Path LIKE '/tv/%' - Radarr:
UPDATE Movies SET Path = '/data/Movies' || SUBSTR(Path, 8) WHERE Path LIKE '/movies/%'
5. Short episode import workaround
Sonarr's DetectSample check rejects any video file with runtime under 90 seconds as a sample — hardcoded, not configurable. Bluey Minisodes (~90 seconds per episode) trips this check on every orphan/path scan, silently failing to import. The workaround is to copy files directly into the series library folder and trigger RescanSeries via the API, which scans existing files without the sample check. This was used to recover S02E05 and S02E10.
6. Automated queue cleanup
Stale completed and warning queue entries accumulate from TorBox API errors and sample-detection failures. Added a weekly cleanup script at /home/plex/bin/sonarr-queue-cleanup.sh that removes queue entries older than 1 hour in those states, without blacklisting releases. Runs every Sunday at 03:00 (slotted between backup jobs). Log at /home/plex/.cache/sonarr-queue-cleanup.log.
7. TorBox DATABASE_ERROR (external, not fixable)
RDTClient logs were full of DATABASE_ERROR: There was an error processing your request from TorBox's API when requesting download links for cached content. This is a TorBox server-side issue — nothing to configure locally. It causes the "queued for downloading" stuck status and the 5–10 minute delays before Sonarr's WaitForTorrent times out. Resolves on its own when TorBox recovers. Increased retry counts partially mitigate it.
With FinishedAction=0, the download-but-never-import failure mode is resolved for normal content; short episodes and TorBox error cases are handled by the weekly queue cleanup.
← Back to Admin Hub