nzo_id missing from reply to Sonarr

Get help with all aspects of SABnzbd
Forum rules
Help us help you:
  • Are you using the latest stable version of SABnzbd? Downloads page.
  • Tell us what system you run SABnzbd on.
  • Adhere to the forum rules.
  • Do you experience problems during downloading?
    Check your connection in Status and Interface settings window.
    Use Test Server in Config > Servers.
    We will probably ask you to do a test using only basic settings.
  • Do you experience problems during repair or unpacking?
    Enable +Debug logging in the Status and Interface settings window and share the relevant parts of the log here using [ code ] sections.
Post Reply
Redundant11
Newbie
Newbie
Posts: 5
Joined: November 19th, 2018, 12:22 pm

nzo_id missing from reply to Sonarr

Post by Redundant11 » November 19th, 2018, 12:59 pm

I originally asked this on the Sonarr forums and markus sees the issue, but isn't sure if it's a setting I have or a bug. Here's the scenario:

1. Perform automatic search for some episodes
2. Releases found and sent to SABnzbd
3. SABnzbd determines release is either:
3A. A duplicate NZB and fails it (true; not an issue)
3B. 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[/list]

Forgive me if something I say below is backwards. It's because I'm interpreting what markus said, so I may get mixed up in my understanding.

According to my logs, Sonarr sent the following to SABnzbd for a release which had this issue:

Code: Select all

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 '(removed)' 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 [*****] 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=*****.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. *****
Then, here is the relevant portion of the response from SAB’s history:

Code: Select all

{
  "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": "*****",
  "nzb_name": "*****",
  "nzo_id": "SABnzbd_nzo_ytfi9k",
  "password": null,
  "path": "\\\\?\\C:\\Shares\\3_1 Temp\\NZBDTemp\\*****",
  "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\\*****",
  "url": "*****.nzb",
  "url_info": ""
}
markus had the following to say about this:
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.
I looked through my settings and I'm not seeing anything obvious which would be causing this. Any ideas?

Note that I sanitized everything here as per the rules, but my post on the Sonarr forums has the release info, so I'm not linking to it directly.

User avatar
safihre
Administrator
Administrator
Posts: 2884
Joined: April 30th, 2015, 7:35 am
Location: Switzerland
Contact:

Re: nzo_id missing from reply to Sonarr

Post by safihre » November 19th, 2018, 1:46 pm

That's very strange. What version of Sabnzbd do you use? 2.3.5 or 2.3.6?

This happens all the time, or just with the duplicates?
Are duplicates send to the history or deleted directly?

Redundant11
Newbie
Newbie
Posts: 5
Joined: November 19th, 2018, 12:22 pm

Re: nzo_id missing from reply to Sonarr

Post by Redundant11 » November 19th, 2018, 5:54 pm

I'm on 2.3.5.

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.

User avatar
safihre
Administrator
Administrator
Posts: 2884
Joined: April 30th, 2015, 7:35 am
Location: Switzerland
Contact:

Re: nzo_id missing from reply to Sonarr

Post by safihre » November 20th, 2018, 3:21 am

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.

Redundant11
Newbie
Newbie
Posts: 5
Joined: November 19th, 2018, 12:22 pm

Re: nzo_id missing from reply to Sonarr

Post by Redundant11 » November 21st, 2018, 12:02 pm

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.

Redundant11
Newbie
Newbie
Posts: 5
Joined: November 19th, 2018, 12:22 pm

Re: nzo_id missing from reply to Sonarr

Post by Redundant11 » November 30th, 2018, 4:03 pm

The latest discussion over at Sonarr went like this:
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.
Which led to...
I think failing to add at all would be a falsey response, so shouldn’t be a problem to differentiate the two cases.
I know everyone is busy, so if I need to be the go-between to try and figure things out between the two projects, I'm more than happy to.

User avatar
safihre
Administrator
Administrator
Posts: 2884
Joined: April 30th, 2015, 7:35 am
Location: Switzerland
Contact:

Re: nzo_id missing from reply to Sonarr

Post by safihre » December 1st, 2018, 10:15 am

Can you maybe create an issue at our github? (I can also do it, but this way it's tracked for you to)
Then I'll make it so that it gives an error instead of success true!
(Sorry, I sort of forgot.. Should have done this already!)

Redundant11
Newbie
Newbie
Posts: 5
Joined: November 19th, 2018, 12:22 pm

Re: nzo_id missing from reply to Sonarr

Post by Redundant11 » December 3rd, 2018, 12:42 pm

My pleasure. I created it here: https://github.com/sabnzbd/sabnzbd/issues/1198

User avatar
safihre
Administrator
Administrator
Posts: 2884
Joined: April 30th, 2015, 7:35 am
Location: Switzerland
Contact:

Re: nzo_id missing from reply to Sonarr

Post by safihre » December 3rd, 2018, 3:16 pm

Thanks! Will think how to solve this, since it's an API change.

Post Reply