Old downloads appear in Queue

Help & Support
#1

Pretty strange issue, first time I’ve had this happen. Basically I have 3 episodes downloaded from a month ago, they are added to my library and Sonarr still sees them just fine (and they meet cutoff).

However, within the last day or so, they randomly showed up in my queue again, with warning - “No files found are eligible for import”. Not sure why Sonarr is suddenly trying to re-import these particular episodes, I didn’t change any quality settings or such. I also checked history and the episodes did not re-download or something like that.

Any reasons you can think of that this would happen?

Edit: The scheduled tasks seemed to clear this out, after a restart of Sonarr.

Edit 2: and now… it is back again…

Queue not updating/linking torrent ID after NAS upgrade - all old items back in queue
#2

Sonarr uses its history to determine if its imported a specific file before, using the path and the download client’s ID for the that item in its history.

Did the scheduled tasks stop running? Did they stop running again when it re-appeared?

#3

Scheduled tasks seem to be running normally. I just tried running the “Housekeeping” one manually (not sure what it does?), thinking it might help.

It seems to actually be unrelated to scheduled tasks though, since just a regular restart of server clears out the queue it looks like. Then they re-appear shortly after. Does this mean the download client is reporting them finished over and over?

Tried shutting down uTorrent, restarting Sonarr, then starting uTorrent back up. No luck though, shortly after starting uTorrent the episodes show back up in the queue again.

Edit:

Just saw this message above the quote, missed it the first time. So, the download/import still shows up in Sonarr’s history, and the actual files are still there in-place. If it receives a different downloadID from uTorrent, will it ignore that? Is there any way to debug that portion to see what could be happening?

#4

Shortly after startup Sonarr will talk to the download client to see what is currently downloading and what is available to import.

For uTorrent Sonarr uses the Torrent Hash to track the download, which shouldn’t change unless the torrent was redownloaded and the hash changed on the tracker. Failing to match based on the ID, I believe we check the path (@Taloth do we still check the path?).

Have any changes been made to those torrents?

Is there any way to debug that portion to see what could be happening?

I’m not sure that we log a lot of information on this process, checking trace logs will show you the full process of what is logged, enabling trace logging, clearing the logs and restarting Sonarr will give the clearest picture of whats happening.

If you want a quick fix, changing the category in uTorrent will stop Sonarr from tracking it (assuming the Hash isn’t being tracked).

#5

No changes have been made to the torrents, at least none that I know of. The modified dates on the files also haven’t changed at all, if that is any reassurance.

I turned on trace logs and dug into them a bit. It doesn’t seem to give info on the logic behind why it tries to import those particular torrents. However, I did notice kind of oddly that the title/quality parser seems to run twice in a row for these, but not for any of the other torrents (at least not that I saw). It is on the second parse than it then tries to send it along to the import task. The data returned from uTorrent further up in trace log doesn’t show multiple torrents for that name though, so not sure what is going on.

Here is an example of the data returned by uTorrent, if that helps at all -

["F057813C69A8CD800CE59885C3887B0E20CF7F4A",201,"{SHOW_NAME}.1x01.720p_HDTV_x264-FoV",1389759391,1000,1389759391,473353119,340,0,0,2015302338,"Sonarr",0,4,0,23,65536,-1,0,"","","Seeding 100.0 %","57e0741f",1453166343,1453166561,"","E:\\{FILE_PATH}\\{SHOW_NAME}.1x01.720p_HDTV_x264-FoV",0,"84ADA81C"],

#6

I assume thats the Torrent Hash (since it looks like one and there aren’t identifying marks on any of the info. I you check in Sonarr’s database (nzbdrone.db in Sonarr’s AppData directory, its SQLite) at the history table there should items that match it (if not that explains the disconnect).

SELECT * FROM History WHERE DownloadId = 'F057813C69A8CD800CE59885C3887B0E20CF7F4A' - There will be one event for the grab and another for the import (EventType 1 and 3 respectively I believe).

#7

Checked it out and none of the hashes show up in the DB. However, it does have entries for the 3 affected episodes in history, they just all have NULL downloadID’s/hashes.

#8

Import or grab events? If the events are imports does the path in the history table match the path that uTorrent is reporting?

#9

Sorry, forgot to say, these are 3 import events (#3). They grab event (#1) seems to be missing for these particular episodes, maybe that is the problem? The grab event is present for other episodes in the series besides these.

The import path in history table does match the path uTorrent is reporting.

#10

Its possible they came from before Sonarr was tracking the hash or it was added outside of Sonarr.

Since the path is the same I’d expect that we match based on that and ignore it, but there may be a reason why we don’t do that (one that comes to mind is re-downloading something that was deleted and we’d block and ignore it based on the path being the same).

#11

Well the weird thing to me is that seemingly nothing changed (with the files, or with Sonarr’s code/logic), and still one day it decided to start queuing them for import again.

But, might have to just write this one off as a fluke I guess?

#12

Definitely strange.

Do you have Drone Factory configured in Sonarr (and using it for importing)?

#13

Nope, my drone factory field is blank, although interval does say 1 minutes, but I’m assuming that is default since I’ve never touched it.

#14

Yeah thats the default. Not sure what else it could be in this case, I’m up for calling it a fluke and hoping it never happens again. :smile:

#15

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