SABnzbd Forums

shypike wrote:What is visible in SABnzbd's logging?

Debug logging is not enabled so I don't think I'll see anything useful. I'll enable it again and wait for another occurrence.

Another instance of this issue happened and here are the logs:

https://www.dropbox.com/s/ayrp2ll70gj34 ... s.zip?dl=0

The release that was aborted was this: DCs Legends of Tomorrow S01E15 Destiny 720p WEB-DL DD5 1 H264-LoT-Obfuscated

Sonarr deleted it from its queue and sent an API request to SAB to delete it from its history but it is still there. Any thoughts?

Received. Will take a while, I'm on holiday.

I can clearly see the delete command:
2016-05-21 14:31:04,805::DEBUG::[interface:458] API-call from 127.0.0.1 [Sonarr/2.0.0.4146 (Windows 6.2)] {'apikey': u'9b92b6918ceabe99645ba82e02b3167d', 'name': u'delete', 'value': u'SABnzbd_nzo_bjiaof', 'del_files': u'1', 'mode': u'history', 'output': u'json'}

But I also see that "DCs Legends of Tomorrow S01E15 Destiny 720p WEB-DL DD5 1 H264-LoT-Obfuscated" occurs twice in the queue, first time it was aborted but the second time it was completed correctly (also note the times):
2016-05-21 14:37:08,726::DEBUG::[tvsort:210] Found TV Show - Starting folder sort (DCs Legends of Tomorrow S01E15 Destiny 720p WEB-DL DD5 1 H264-LoT-Obfuscated)
Sonarr probably grabbed the same release twice (maybe from multiple indexers?).

So just to be 100% sure that we get it correctly, the Failed job (not the completed) is still in the history with it's red status and it also has the Retry option available?

You're actually right but looking at the screenshots below, the same release was actually downloaded thrice. The first try failed, Sonarr deleted it and the deletion was successful in both sides (which is why we don't see it in the History of SAB anymore). The second try failed again, Sonarr deleted it but was only deleted on Sonarr's side (this is what we're concerned about). The third try was successful and the import was successful thus showing completed in SAB's history.

https://www.dropbox.com/s/05geqntx4edbl ... e.JPG?dl=0
https://www.dropbox.com/s/05geqntx4edbl ... e.JPG?dl=0

No, Sonarr could've not grabbed it from multiple indexers as there's only one indexer set there (NZBGeek). Could it be just the same release name but really different content inside or probably a re-uploaded NZB? I mean if it's the same exact release, why would it fail during the first and second tries and complete it on the third?

kevindd992002 wrote:Could it be just the same release name but really different content inside or probably a re-uploaded NZB?

Totally possible... some things are uploaded 10-20+ times.

kevindd992002 wrote:I mean if it's the same exact release, why would it fail during the first and second tries and complete it on the third?

Propagation?

Gotcha. So from what I see, it really seems to be a problem in Sab as the API commands are being recieved successfuly from Sonarr. Could it still be the timing issue that was discussed earlier and was supposed to be fixed already?

I think I see this as well. Before upgrading to 1.0, re-downloading failed downloads worked very well. Now with 1.0, no re-download happens, since Sonarr still believes that Sabnzbd is still downloading. At least it looks like that in Sonarr.

Per

Edit: I just saw version 1.0.2, will try that version.

I don't think your case is exactly the same as mine though. What happens in mine is that Sonarr definitely knows that the download failed but there are very few instances (out of the many successful ones) that Sab doesn't delete the failed download from its history even though Sonarr asks it to do so.

Yes, you are right, not the same as my error.

Per

Pjakesson: it might be a different bug that we fixed in 1.0.2 for your case, situations where Sonarr didn't get the right info.
Going to look more in your logs again Kevin, hope it clears something up. It shouldn't be the timing issue..

Thanks for the information safihre. I just upgraded to 1.0.2, and hoping re-downloads will work again.
And thanks for your excellent work with Sabnzbd.

Per

PS. And sorry for hi-jacking Kevins thread.

There is nothing in the log that can explain it... The job is shown as failed, Sonarr sends the delete command (5 min later, so not a race-condition clearly), but your screenshot still shows it...

Can it be considered a bug then?

Definitely a bug, but one that has not been reported at all before.. Almost impossible to reproduce, I use sonarr myself for many months but never have this.

Maybe shypike will know a way to figure out what's going wrong?
I am surprised though that besides the API request there is no other logging at all what it is doing. And always returns true. Remember this for some other command too.