Describe the bug
watch_for_import polls is_imported() in an unbounded loop and only exits when all of a transfer's video files are imported. If a transfer contains a video file the *arr will never import — most commonly a sample that isn't inside a skip_directories folder — is_imported() never returns true and the task loops forever.
Each such transfer leaves a forever-running task polling the *arr/put.io APIs every polling_interval. They accumulate over time; after ~10h with a large Radarr/Sonarr library on put.io, the process stops picking up newly-completed transfers entirely (downloads stall with many COMPLETED transfers sitting on put.io un-pulled). A restart clears it temporarily.
Evidence
The log repeatedly prints found imported by radarr for the main file of the same transfer every ~10s — Radarr imported the movie, but the transfer never completes because a sibling sample file is never imported, so is_imported() stays false and watch_for_import keeps looping.
[... 50bf: .../The.Wages.of.Fear...mkv]: found imported by radarr (radarr)
[... 50bf: .../The.Wages.of.Fear...mkv]: found imported by radarr (radarr) # same transfer, ~20s later
Proposed fix
Bound watch_for_import with a give-up timeout: stop watching (and warn) after N hours so stuck transfers can't accumulate and starve the downloaders. Genuine imports complete within a poll or two of the *arr importing, so a generous bound doesn't affect normal operation.
The deeper fix is better import-mapping (the existing skip_directories TODO) — e.g. ignore sample files, or treat a transfer as imported once it has left the *arr download queue.
Environment
- putioarr current
main / v0.6.6, Docker
- Large Radarr/Sonarr library being pulled from put.io
I can open a PR for the bounded-loop fix.
Describe the bug
watch_for_importpollsis_imported()in an unboundedloopand only exits when all of a transfer's video files are imported. If a transfer contains a video file the *arr will never import — most commonly a sample that isn't inside askip_directoriesfolder —is_imported()never returns true and the task loops forever.Each such transfer leaves a forever-running task polling the *arr/put.io APIs every
polling_interval. They accumulate over time; after ~10h with a large Radarr/Sonarr library on put.io, the process stops picking up newly-completed transfers entirely (downloads stall with manyCOMPLETEDtransfers sitting on put.io un-pulled). A restart clears it temporarily.Evidence
The log repeatedly prints
found imported by radarrfor the main file of the same transfer every ~10s — Radarr imported the movie, but the transfer never completes because a sibling sample file is never imported, sois_imported()stays false andwatch_for_importkeeps looping.Proposed fix
Bound
watch_for_importwith a give-up timeout: stop watching (and warn) after N hours so stuck transfers can't accumulate and starve the downloaders. Genuine imports complete within a poll or two of the *arr importing, so a generous bound doesn't affect normal operation.The deeper fix is better import-mapping (the existing
skip_directoriesTODO) — e.g. ignore sample files, or treat a transfer as imported once it has left the *arr download queue.Environment
main/ v0.6.6, DockerI can open a PR for the bounded-loop fix.