Correct.
No, Sonarr tells SAB to remove it from its history and adds it to the blacklist at the same time, removing it from Sonarr’s blacklist won’t do anything.
Can you suggest of any easier way to replicate this? I can’t leave trace logging enabled all the time until the issue fails since it will saturate disk space, right?
The easiest way would be to grab things that you expect to fail.
It will use a maximum of 51MB of disk space.
I grabbed that same blacklisted Constantine series and Sonarr was able to delete if from SAB’s queue. This simply means that this problem is really random as I’ve explained in my previous posts. It mostly happens when there are multiple releases in SAB’s queue. If you check the earlier posts of this thread, someone from the SABNZBD forums was explaining that this could be a “sync” problem between the two programs. Have you thought anything about that possible issue route?
Sonarr makes the request to delete it every time there is a failure, if it randomly doesn’t delete I don’t see this being a Sonarr issue, which is why we need to know what response SAB retrurns.
The post on the SAB forum eludes to Sonarr asking SAB to delete it and SAB is in a state where it can’t remove it, since it is flipping between queue/history, if that’s the case SAB should be telling Sonarr that’s the case (response from SAB indicates that it can’t be found), which we should be able to deal with, if SAB tells Sonarr it was removed then Sonarr needs to trust that it was actually removed.
Until we know how SAB is responding we can’t begin to look for a solution.
Finally, after months of keeping trace logging enabled I was able to capture a failed download that was not deleted from the SAB history. I’ve uploaded all the logs I can get, please download them from here for your reference:
The name of the release in question is “Continuum.S04E03.Power.Hour.1080p.WEB-DL.DD5.1.H.264-NZBgeek” and has been in the “Aborted, cannot be completed” stage in SAB. I’ve tried searching for this text in all the log files and it seems that it is present in most of them which is why I decided to just upload all the files to you, just to be sure.
Thanks.
I’m expecting to see an event in the logs that shows Sonarr attempted to delete it, but I’m not seeing one. Is there a failed download event in Sonarr’s history?
The message I expect to see is similar to this:
[Continuum.S04E03.Power.Hour.1080p.WEB-DL.DD5.1.H.264-NZBgeek] Removing download from DOWNLOAD_CLIENT_NAME history.
Yes, there is. This is the information for that event in Sonarr’s history:
Name:Continuum.S04E03.Power.Hour.1080p.WEB-DL.DD5.1.H.264-NZBgeek
Message:Aborted, cannot be completed
So it does have the same message as that of SAB’s but Sonarr did not attempt to delete it for some reason as observed in the logs.
When was that event created in Sonarr’s history, that will narrow down where to look in the logs since those actions both are triggered by the same event.
Sunday, September 20, 2015, 7:31 PM (GMT+8)
Unfortunately, the oldest event in the logs (nzbdrone.49.txt) is from: 15-9-20 20:28:02.7, an hour after history event, so we can’t see the attempt from Sonarr to SAB to remove the item and what the response from SAB was, which is what I’m assuming is the issue we’re trying to troubleshoot (60 posts later I’m not sure).
Is that because it was already replaced by newer events? I kept trace logging enabled the whole time until this event occurred.
Yes, by the time the logs were zipped up the oldest log was about 1 hour older than the history event, which we needed to see in the logs.
Another instance of the problem happened again and I really hope these logs will already show us the problem. This happened just now. Please check these for your reference:
The release that was not deleted by Sonarr is:
Blindspot.S01E06.1080p.WEB-DL.DD5.1.H.264-NTb-NZBgeek
I see two cases in the logs where Sonarr asked SABnzbd to remove a release with that name and in both cases SABnzbd responded indicating that the release was removed:
15-10-29 13:32:18.3|Debug|SabnzbdProxy|Url: http://localhost:8080/api?mode=history&name=delete&del_files=1&value=SABnzbd_nzo_ze979d&apikey=<removed>&output=json
15-10-29 13:32:18.4|Trace|SabnzbdProxy|Response: {"status":true}
15-10-29 20:21:13.7|Debug|SabnzbdProxy|Url: http://localhost:8080/api?mode=history&name=delete&del_files=1&value=SABnzbd_nzo_z-_rka&apikey=<removed>&output=json
15-10-29 20:21:13.8|Trace|SabnzbdProxy|Response: {"status":true}
So does that mean SAB is the culprit?
It looks that way.
How do I get guys from both sides to work together on this? Should I file another case on SAB’s forum?
I’m not sure there is much that is needed from us, your logs show the request from Sonarr to SAB and SAB’s response.