nzo_id missing from reply to Sonarr
Posted: 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:
Then, here is the relevant portion of the response from SAB’s history:
markus had the following to say about this:
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.
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. *****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": ""
}I looked through my settings and I'm not seeing anything obvious which would be causing this. Any ideas?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.
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.