SABnzbd Forums

Interesting scenario.
I would have to look at whether SABnzbd shows a confusing status at any time.
I'll keep this in mind when I look into this later.

Hey folks,

Didn't see the thread on nzbdrone's forum until now, otherwise I would've responded earlier.

For failed download handling drone simple checks the status == failed. So if sabnzbd reported that status after repair before sending it back to the queue, that could be a problem.
But I took a quick peek in sabnzbd code and it doesn't seem to do that, but that's just from what I could glance.
It could be timing as shypike suggest, if sabnzbd sets it to failed on the api before committing it in the history db, but that's gotta be a matter of milliseconds.
Drone saves the download as failed in his own database before actually calling the sabznbd api to remove the failed item. So that should easily cover any delay sabnzbd may have needed.

Anyway, kevin, we should really get some correlation between the nzbdrone log and sabnzbd log. I suggest you enable loglevel trace and let it run, it will output significantly more log entries, but nzbdrone uses log rotation too.
I hope you get the issue frequently enough, otherwise this could be a long story. With trace level on the api response is logged as well (so every minute). So it should tell us what sabnzbd returns and what actions drone takes.

Btw. The nzbdrone log output for it changed since the last version. After 3 weeks in beta we released the completed download handling feature.
Instead of periodically scanning the disk for completed downloads (and check for UNPACK), we now actively poll the sabnzbd api and thus wait for unpack and post-processing scripts to finish, which could be a blessing for those with transcoding/subtitle pp-scripts. Previously the api was only polled for failed download handling.
This does mean quite some code changes, it shouldn't affect this particular issue, but I figured it was important to mention.

One of the other nzbdrone devs, btw. (check with markus if you need verification)

I'm sorry, I was very busy for the past few months bug I'm ready to check on this again. This is still happening when I search all episodes of one season.

Taloth, how do I enable loglevel trace to provide you the logs I need?

Kevin, recently nzbdrone was updated (within the past few days) so try updating, maybe the issue has been resolved.

The issue is still happening. I freshly installed on two computers and it is still happening.

Updates on this please?

I have to do some more testing, but from what I have seen so far:
There's no incorrect status when a failed job is sent back to the queue.
The ID of the job stays the same.

Maybe it's worth talking to markus101 or one of the other devs over on the sonarr (NzbDrone) forum to resolve this.

shypike wrote:The ID of the job stays the same.

Hey shypike using where nzoid is the ID of the job in history we are seeing the ID change in 0.7.18 (and previously in 0.7.16), if the retry did not go back to the queue, but instead the post processing queue we are seeing the ID change as well. Is there a different call we should be making?

By ID changing I mean if we look for an item in queue/history with the old ID we do not find one.

Markus101, thanks for chiming in. I hope we can work this issue out with shypike. Let me know if you need any logs from me.

When a job is automatically sent back to the download queue, its nzb_id will not change.
However, when a "Retry" is done (manually of through the API), the job will get a new nzo_id.

I can change the "Retry" api-call so that it will return this JSON output: That way you will know the new nzo_id.

Okay, that makes sense, thanks for confirming.

That change would definitely make things more reliable and would be awesome, currently we check the queue and history for it and log if we can't find it, so I don't think its the source of this issue.

markus101 wrote: so I don't think its the source of this issue.

I cannot think of what else.
I saw another tiny issue, which maybe could be a factor.
When the last par2 files are fetched, but it is already clear that it won't be enough,
the status goes to "Failed". This is not correct: the status should be "Fetching".
But this affects only downloads that are going to fail anyway.

Well, what do you think markus101?

Sonarr (NzbDrone) won't remove attempt to remove something if its not in queue/history. I think from here Debug logging for both Sonarr and SAB would be helpful to see the call from Sonarr to SAB since there have been a number of changes on the Sonarr side (2.0.0.2180). Also make sure Retry is set to 0 in failed download settings (advanced): https://db.tt/QAHLnjnL - which will eliminate retrying causing issues, if there are still issues then we know to look elsewhere.