Same releases downloaded again after being blacklisted

Help & Support
#1

Sonarr version (exact version): 2.0.0.5252
Mono version (if Sonarr is not running on Windows): N/A
OS: Windows 10 Pro
Debug logs: https://www.dropbox.com/s/mf8keoiba1wqr3y/LogFiles.zip?dl=0
Description of issue:

  1. Perform automatic search for some episodes
  2. Releases found and sent to SABnzbd
  3. SABnzbd determines release is either:
    A. A duplicate NZB and fails it (true; not an issue)
    B. A release which cannot be completed (true; not an issue)
  4. Sonarr marks release as “Download wasn’t grabbed by sonarr, skipping”
  5. (Issue #1) Sonarr queue holds these forever and never tries to download other releases
  6. In Sonarr queue, I click “Remove from download client” and then choose to blacklist the release and remove it
  7. Release disappears from SABnzbd’s history and Sonarr’s queue
  8. (Issue #2) Perform another automatic search in Sonarr and the same release is put back into the SABnzbd queue

I’ve been seeing this sequence for some time now, but finally decided to document the issue and report it here. If this is a bug, I’ll gladly create an entry on Github.

#2

If SABnzbd changes the ID of download, which it used to do when pre-checking downloads then Sonarr will never know the download it sent was the one that failed. I believe they did some work to fix that a while ago, but in any event pre-checking is not recommended (and may have been replaced).

If the download isn’t known blacklisting won’t have an effect because Sonarr is lacking the information it needs to blacklist the release (the information in history for the grabbed event). Disabling blacklisting for items Sonarr can’t actually blacklist may be tricky, but something I can look into.

As for the underlying issue, which version of SABnzbd are you using?
Are you pre-checking downloads?
What is Detect Duplicate Downloads set to?

#3

I’m running SABnzbd version 2.3.5 [76c7a6c], which is the latest one available.

I used to use pre-checking, but turned that off today as I started documenting this in order to post here. It is quite possible it was enabled the first time I searched for the episodes in the log files. Not sure if that would have a sort of lingering effect on subsequent searches for the same episodes.

“Detect Duplicate Downloads” and “Detect duplicate episodes in series” are both set to “Fail job (move to History)”.

Let me know what other info or test results I can provide.

#4

Only for downloads that were sent while the setting was enabled.

Trace logs would be helpful, they will show the responses from SAB for the history (when Sonarr
discovers the failed download) and should include the response when the NZB is initially queued. Depending how long it takes from add until SAB failing the download and Sonarr fetching the history the responses may span a couple logs.

#5

Ok, good. Then I don’t need to do it again with different episodes.

The Dropbox link I provided has trace logs in it. I tried to provide as much info as possible when I posted. :slight_smile:

#6

Have a particular release name contained in those logs I can look for? I’m not going to sift through them line by line.

#7

I don’t blame you one bit! That’s a lot of lines! Try this one:
Orange.Is.the.New.Black.S03E02.720p.WEBRip.x264-2HD

#8

This is where it’s sent to SAB:

18-11-15 13:15:14.5|Trace|HttpClient|Req: [GET] https://api.omgwtfnzbs.me/api?t=get&id=G51Hm&apikey=(removed)
18-11-15 13:15:14.5|Trace|ConfigService|Using default config value for 'proxyenabled' defaultValue:'False'
18-11-15 13:15:15.3|Trace|HttpClient|Res: [GET] https://api.omgwtfnzbs.me/api?t=get&id=G51Hm&apikey=(removed) 200.OK (768 ms)
18-11-15 13:15:15.3|Debug|Sabnzbd|Downloaded nzb for episode 'Orange.Is.the.New.Black.S03E02.720p.WEBRip.x264-2HD' finished (229908 bytes from https://api.omgwtfnzbs.me/api?t=get&id=G51Hm&apikey=(removed)
18-11-15 13:15:15.3|Info|Sabnzbd|Adding report [Orange.Is.the.New.Black.S03E02.720p.WEBRip.x264-2HD] to the queue.
18-11-15 13:15:15.3|Debug|SabnzbdProxy|Url: https://w7-server:9095/api?mode=addfile&cat=tv&priority=-1&apikey=(removed)&output=json
18-11-15 13:15:15.3|Trace|HttpClient|Req: [POST] https://w7-server:9095/api?mode=addfile&cat=tv&priority=-1&apikey=(removed)&output=json: 
name=Orange.Is.the.New.Black.S03E02.720p.WEBRip.x264-2HD.nzb (229908 bytes)
18-11-15 13:15:15.3|Trace|ConfigService|Using default config value for 'proxyenabled' defaultValue:'False'
18-11-15 13:15:15.3|Debug|X509CertificateValidationPolicy|Certificate validation for https://w7-server:9095/api?mode=addfile&cat=tv&priority=-1&apikey=(removed)&output=json failed. RemoteCertificateNameMismatch
18-11-15 13:15:15.7|Trace|HttpClient|Res: [POST] https://w7-server:9095/api?mode=addfile&cat=tv&priority=-1&apikey=(removed)&output=json: 200.OK (408 ms)
18-11-15 13:15:15.7|Trace|HttpClient|Response content (31 bytes): {"status": true, "nzo_ids": []}
18-11-15 13:15:15.7|Info|DownloadService|Report sent to SABnzbd. Orange.Is.the.New.Black.S03E02.720p.WEBRip.x264-2HD

And here is the relevant portion of the response from SAB’s history:

{
  "action_line": "",
  "bytes": 0,
  "category": "tv",
  "completed": 1542305716,
  "completeness": 0,
  "download_time": 0,
  "downloaded": 0,
  "fail_message": "Duplicate NZB",
  "has_rating": false,
  "id": 6335,
  "loaded": false,
  "md5sum": "399f14d87d7b49deff0fc3e8ebf35a3a",
  "meta": null,
  "name": "Orange.Is.the.New.Black.S03E02.720p.WEBRip.x264-2HD",
  "nzb_name": "Orange.Is.the.New.Black.S03E02.720p.WEBRip.x264-2HD.nzb",
  "nzo_id": "SABnzbd_nzo_ytfi9k",
  "password": null,
  "path": "\\\\?\\C:\\Shares\\3_1 Temp\\NZBDTemp\\Orange.Is.the.New.Black.S03E02.720p.WE.4",
  "postproc_time": 0,
  "pp": "D",
  "report": "",
  "retry": 1,
  "script": "None",
  "script_line": "",
  "script_log": "",
  "series": "",
  "show_details": "True",
  "size": "",
  "stage_log": "",
  "status": "Failed",
  "storage": "C:\\Shares\\3_1 Temp\\NZBDTemp\\Orange.Is.the.New.Black.S03E02.720p.WE.4",
  "url": "Orange.Is.the.New.Black.S03E02.720p.WEBRip.x264-2HD.nzb",
  "url_info": ""
}

The important part is SAB accepts the NZB, but doesn’t return a nzo_id for it, which means Sonarr has no way to track it.

A search of your logs shows every queued NZB has that problem, (the lines above Report sent to SABnzbd. all show Response content (31 bytes): {"status": true, "nzo_ids": []}) so it’s not special for this download, but would affect any download that fails.

This is what a proper response looks like:
18-11-16 16:57:29.5|Trace|HttpClient|Response content (51 bytes): {"status": true, "nzo_ids": ["SABnzbd_nzo_D8KY2K"]} (I’m getting that back from SAB 2.3.4 [2a113f7]).

I’m not sure if that’s a bug in 2.3.5 or due to a setting.

#9

I posted on the SAB forums and we discovered the following:

I was able to verify that when the grab is successful, the nzo_id comes through CORRECTLY.

The blank nzo_id appears to only occur when some combination of “Abort jobs that cannot be completed”, “Detect Duplicate Downloads”, and “Detect duplicate episodes in series” is in place. I haven’t tested every combination, but having settings of “ENABLED”, “FAIL”, and “FAIL”, respectively, is a scenario when the nzo_id is always EMPTY.

I also saw at least once instance where having “Abort jobs that cannot be completed” DISABLED caused the nzo_id to come through CORRECTLY, but I don’t recall how I had the other two switches set.

Duplicates wind up in history for both SAB (showing “duplicate nzb” or “aborted, cannot be completed” and Sonarr’s queue (showing “download wasn’t grabbed by Sonarr, skipping”), but when I clean up Sonarr of the release, it deletes them from SAB’s history.

safihre’s response to this situation was:

Blockquote
So the problem seems to be the interpretation of success:true but with empty list.
We only give nzo_id if it was successfully added, while sucess:true is just to report that the adding was sucessful.
So I think Sonarr should interpret the lack of nzo_id’s as a failure to add. But then again it’s not very pretty.

I’m not sure where we go from here.

#10

A combination I’ve found to work around this disconnect between the two programs is having SAB’s “Abort jobs that cannot be completed” enabled with both duplicate detection switches turned off. An nzo_id seems to always be sent in this instance, so Sonarr knows whether or not to try another release. It’s a bit of a waste of bandwidth and time, but at least it doesn’t require manual intervention for every duplicate and failure.

#11

We could treat true without a nzo_id as a failure to add, but that wouldn’t blacklist the release, it’d just move onto the next. The problem is with that behaviour is Sonarr would continually try those releases each time. We have a similar issue with NZBget’s duplicate detection as well.

#12

@markus101 We could do what we planned with nzbget, to have the download client instance throw something like ReleaseFailedException and handle that by putting them on the blacklist (unlike ReleaseUnavailableException, which just ignores them).
The problem I’m having is that the 'success':true, nzo_id:[] doesn’t say WHY it failed. So ideally we should get back the exact reason from sab, so we can differentiate between failed to add, and download failed.

#13

I think failing to add at all would be a falsey response, so shouldn’t be a problem to differentiate the two cases.

#14

SAB asked me to enter an issue on their Github, which I’ve done (https://github.com/sabnzbd/sabnzbd/issues/1198).

They’ve stated that they are going to make SAB return an error when this happens.

#15

Awesome, we should be able to better handle that scenario once we know what SAB is going to return, I’ve subscribed to their issue to track it.

1 Like
#16

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