Sonarr not moving (some) files after download

Sonarr version (exact version): 3.0.7.1477
Mono version (if Sonarr is not running on Windows): 6.12.0.122
OS: Truenas SCALE / Truecharts Image
Debug logs: [link] - The episode downloaded but not moved in this log file is ‘Servant.S03E09.Commitment.720p.ATVP.WEB-DL.DDP5.1.H264-CasStudio[rartv]’
Description of issue:

So Sonarr sometimes moves a file after download, sometimes doesn’t and I’m trying to understand why.

After browsing through my debug logs, my understanding is that after a download has been triggered in the torrent client 4 events happen leading to a file being successfully downloaded and moved:

1- TrackedDownloadService|Tracking ClientState=Downloading
2- TrackedDownloadService|Tracking ClientState=Completed
3- EpisodeFileMovingService|Hardlinking episode file
4- DiskTransferService|HardLinkOrCopy

So Sonarr needs to check on download progress and get a ‘completed’ response in order to trigger the move, makes sense.

In the log linked above, I do see the ClientState=Downloading entry for the episode in question, but that’s the only TrackedDownloadService query in the file, it nevers gets to ClientState=Completed and no EpisodeFileMovingService entry at all, which again makes sense, it won’t even attempt to move what it doesn’t know has been completed yet.

So I’ve pinpointed the issue there, but I don’t see any TrackedDownloadService errors anywhere, so not sure why that ClientState=Completed is never received by Sonarr, so I stalled there.

What am I missing here? Where should I look next?

As a side note, my torrent client is qbittorrent 4.4.1, and I have read in the documentation that 4.4.0 was not supported, but also read that 4.4.1 fixed the issue and has been rock solid for people apparently.

Thanks!

  1. your sonarr is out of date upgrade
  2. what do you have hitting the status endpoint every few seconds and why?
  3. what was unclear on the gathering log section of the wiki to not get logs when an RSS refresh is going on it makes the logs rather spammy?
  4. a+ Effort on digesting the logs, but the time stamps would have been even more helpful
  5. I don’t see how 1.5 hours of logs covering over 10,000 lines that do not show anything to do with an import, attempted, failed, import, or any error at all is relevant to your issue nor why you shared logs that have no relevance to the issue. Please review the wiki for how to gather and share useful logs in the future.

see the download troubleshooting guide; 99% chance your issue is one of those common problems - typically poor paths, ownership, and permissions. https://wiki.servarr.com/sonarr/troubleshooting#downloads-and-importing

My bad on the log instructions, I missed that section of the wiki.

Anyway I think figured it out, not a common problem, I had everything set up properly. Also as I stated in the OP some files would still be imported properly, just not consistently, and the system or logs would not throw any error either in those instances (which I’m pretty sure it would for something as basic as a permission or path issue). As I said, It just looked like Sonarr was simply never getting the download complete status and therefore never even attempting some imports, which I couldn’t make sense of.

So I went back and checked all the settings again for the hundred time and I realized that I had entered .1 instead of 1 for seed ratio in one of the indexer (you guessed it, the one those failed imports torrents were from), so I fixed that and sure enough it fixed things.
So I just think that since it was set to “0.1”, which would be reached by the time the download is completed for any popular torrent, qbittorent was basically almost instantly removing downloads after they complete, so I guess because those torrents were removed so quickly, Sonarr just didn’t have time to grab the complete status, and therefore would never trigger the import. Seems silly, but mystery solved.

Ah Qbit should be set to pause on completion and not remove.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.