Nzb.su api issue - nzb.su or Sonarr problem

Help & Support
#1

I’ve had a problem for a while with the API from nzb.su. I’m not sure when it started, but it’s been going on or a while now. I’m not sure how to dissect the errors I’m seeing and to figure out if it’s Sonarr acting up or the problem is on nzb.su side.

Here is the first of two errors:

And here is the second,

I can https to the api.nzb.su site without issue, so I know it’s working from that standpoint. I’m well under my API limit as well. I’m thinking it is on their side, but I’m not really sure how to verify that.

#2

A 503 error means its something on their end.

I know nzb.su will block requests if a large number of requests are made in a short time frame, but that doesn’t appear to be the case here (and if thats what they are trying to achieve here the response code is wrong).

#3

A 503 error means its something on their end. I know nzb.su will block requests if a large number of requests are made in a short time frame, but that doesn’t appear to be the case here (and if thats what they are trying to achieve here the response code is wrong).

For me that is exactly the case. It is reproducable every time. If I search 1 episode, no problem, as soon as it tries to search in bulk NZB blocks Sonarr.

See this post - Sonarr hammering

The NZB.su team member described what was happening and what Sonarr needed to do but there has been no update or response since.

Sonarr is not pausing between its episode requests and hammers the API, so nzb.su has no choice but to block it for 15 minutes.

There is now ay for users of Sonarr to stop this behaviour other than only ever searching for 1 episode at a time, waiting, then searching the next.

The ball is in Sonarr’s court, we are waiting for this usability fix for a month now which is as simple as putting a pause for 4-5 seconds between index searches.

#4

503 Service Unavailable
The server is currently unavailable (because it is overloaded or down for maintenance). Generally, this is a temporary state.

A 429 is an acceptable response to rate limiting, a 503 leads me to believe there is a problem with the server.

Yes, I’m aware of that thread and we implemented a backoff for grabs. https://github.com/Sonarr/Sonarr/commit/1275d8098d80c26a31573abf6ef4caae975b55c6

We have not implemented any backing off for general API calls because its a more more difficult problem to solve, one search is not aware of another or an RSS sync so there is nothing simple about it. We’ll add this to the list of things we need to do in regards searching and RSS, but its not going to be a quick fix.

#5