Sonarr version 2.0.0.4230:
OS: Windows 10 64bit
((Debug logs)):
http://pastebin.com/kCpEGDTm
Description of issue:
Every 5-7 days, I notice noting has been downloaded. I go to the activity queue and everything in the activity queue will have the error “Download wasn’t grabbed by sonarr, skipping”. I have check categories, they are correct. Have checked the download handler, it is correct.
Any help would be appreciated.
We need to see full ((debug logs)), those are truncated and don’t appear to be debug. In This case ((trace logs)) would be even more helpful to see the response NZBGet returned in that failure.
Ok, I enabled trace. Will have to return once it happens again. Thanks
OK so i came here to report the same issue. I believe it has something to do with NZBGet 17.0 as it only started happening when i upgraded to v17.0.
When Sonarr grabs a release, tries to download it and it fails, it removes the download from NZBGet and then tries to download it again at the next RSS sync. This was no problem in v16.x of NZBGet as Sonarr was removing the entry WITHOUT any history tracking.
In version 17, when you re-add an identically named NZB, it adds it with a status of COPY (New status as far as i can tell) and doesn’t download anything. Sonarr then sees this in the history and says it didn’t download it so it skips it. If you go to the entry in the history and choose Download Again, it will download (successfully this time if it had time to propagate) and Sonarr will pick it up no problem.
It has become quite a PITA as you are never sure if something has downloaded properly.
I noticed that when i delete an entry in NZBGet, it now gives me 4 options instead of 3 asking me what i want to do with the history and downloaded files. Perhaps Sonarr is telling it to keep the history or perhaps it’s just NZBget’s COPY status that is throwing the wrench in our spokes.
Here are some screenshots of the problem in action:
The issue is that the items in history with the status COPY don’t have the ID Sonarr expects them to either because it failed to apply it or because it was stripped by NZBGet when it marked it as a dupe. That status has been around since November 2015 at least (that’s when an issue was opened in our repo to support it) and was added to Sonarr in April in this commit:
It looks like the ID Sonarr is telling nzbget to use is being thrown out when it’s moved to history (Sonarr sends it to NZBGet when it’s queuing it, so it should be applied).
I just had this happen again with a different series. I do have the Debug and Trace logs.
Do you need them? Would prefer to send privately. Somehow I missed the memo on how large the files were and cant take the time to cleanse out personal information (if any)
The ((trace logs)) might confirm the issue, but based on what we see from above it appears to be a nzbget issue (it should respect the ID we’re sending). The logs shouldn’t contain anything personal.
Should we report the issue to the NZBGet dev or did you guys do it already?
I can, but want to confirm the issue, can you post some ((trace logs)) so we can see the history response from NZBGet and confirm its lacking the ID. Also do these grabs show up in Sonarr’s history?
Thanks. Looks like NZBGet has an ID linked to it, we’ll need to do some more testing to see where the issue lies.
Any news on this? When selecting the entry marked as copy in NZBGet and choosing download again, Sonarr picks it up and processes it no problem. It doesn’t complain that it didn’t grab it.
I am still using v17.1 but the testing version 18 seems to have changed something that may be related to this issue… will that alone fix it or do you guys still have to do something?
I think that will help with trying something different immediately, but we’d want to handle it still so we can detect it in the history and not keep trying to send the same release over and over.
I can confirm that moving to the testing version seems to have resolved my problem.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
