Sonarr version (exact version): 2.0.0.4326 Mono version (if Sonarr is not running on Windows): 4.2.3 (Stable 4.2.3.4/832de4b Wed Mar 16 13:19:08 UTC 2016) OS: Ubuntu 16.04 ((Debug logs)):
Description of issue:
I am primarily using Sonarr with torrents and have a number of providers that I use via Jackett as well as RARBG. The issue seems to be that when RARBG is inaccessible for whatever reason, RSS Sync hangs and can be hanging for hours/days if I don’t restart the nzbdrone service. If I do and RARBG is still down, it will hang again. When I disable RARBG and only use Jackett providers, RSS Sync works fine.
RARBG does work when it is accessible so this is mostly around how RSS Sync handles not being able to connect to it. Is there a way to configure RSS Sync to stop waiting or trying to connect after a certain timeout period?
There isn’t anything useful in the logs, usually if RSS Sync is hanging there is nothing, sometimes an “Unable to connect to indexer” error after the fact.
Sonarr should timeout if they don’t respond within 30 seconds. We’d need to see ((trace logs)) leading up to the hanging of RSS sync to investigate further.
I’ve re-enabled rarbg and trace logging. It’s been hanging for the last 90 minutes. Unfortunately, there is nothing useful in the logs. The last log line is
16-10-7 16:32:31.0|Info|RssSyncService|Starting RSS Sync
16-10-7 16:32:37.2|Warn|Torznab|Indexer The Pirate Bay rss sync didn't cover the period between 06/10/2016 20:33:02 and 07/10/2016 08:04:37 UTC. Search may be required.
Now, if I disable RARBG, RSS Sync never hangs (thus far anyhow).
Sorry, I didn’t realize there was a different file for the actual trace logs.
So, I re-enabled and here is the relevant lines I can find:
16-10-10 12:06:29.7|Trace|HttpClient|Req: [GET] https://torrentapi.org/pubapi_v2.php?get_token=get_token
16-10-10 12:06:33.4|Trace|HttpClient|Res: [GET] https://torrentapi.org/pubapi_v2.php?get_token=get_token: 200.OK (3723 ms)
16-10-10 12:06:33.5|Debug|Rarbg|Downloading Feed https://torrentapi.org/pubapi_v2.php?mode=list&ranked=0&category=18%3B41&limit=100&token=(removed)&format=json_extended&app_id=Sonarr
16-10-10 12:06:33.5|Trace|HttpClient|Req: [GET] https://torrentapi.org/pubapi_v2.php?mode=list&ranked=0&category=18%3B41&limit=100&token=(removed)&format=json_extended&app_id=Sonarr
16-10-10 12:06:36.8|Trace|HttpClient|Res: [GET] https://torrentapi.org/pubapi_v2.php?mode=list&ranked=0&category=18%3B41&limit=100&token=(removed)&format=json_extended&app_id=Sonarr: 200.OK (3329 ms)
16-10-10 12:22:00.5|Trace|HttpClient|Req: [GET] https://torrentapi.org/pubapi_v2.php?get_token=get_token
16-10-10 12:22:03.3|Trace|HttpClient|Res: [GET] https://torrentapi.org/pubapi_v2.php?get_token=get_token: 200.OK (2766 ms)
16-10-10 12:22:03.3|Debug|Rarbg|Downloading Feed https://torrentapi.org/pubapi_v2.php?mode=list&ranked=0&category=18%3B41&limit=100&token=(removed)&format=json_extended&app_id=Sonarr
16-10-10 12:22:03.3|Trace|HttpClient|Req: [GET] https://torrentapi.org/pubapi_v2.php?mode=list&ranked=0&category=18%3B41&limit=100&token=(removed)&format=json_extended&app_id=Sonarr
16-10-10 12:23:30.5|Trace|CommandQueueManager|Checking if command is queued or started: RssSync
16-10-10 12:23:30.5|Trace|CommandQueueManager|Command is already in progress: RssSync
16-10-10 12:50:02.0|Trace|CommandQueueManager|Checking if command is queued or started: RssSync
16-10-10 12:50:02.0|Trace|CommandQueueManager|Command is already in progress: RssSync
Some of the lines seem to have a HTTP status at the end (200) and a response time while others not. RSS Sync then seems to be stuck as follow up requests end up with the job still running.
The interesting thing is RARBG has just responded to a token request right before it makes the request to get the feed: 16-10-10 12:22:03.3|Trace|HttpClient|Res: [GET] https://torrentapi.org/pubapi_v2.php?get_token=get_token: 200.OK (2766 ms)
Which is expected to ensure Sonarr has a valid token, but RARBG has recently started enforcing rate limiting on getting a token, so requests to get a token immediately followed by a request to get the feed can fail (though they fail, not silently hang), I wonder if we’re seeing the hanging do to some combination of mono and libcurl that fails silently (just a guess). The next release will respect rate limiting for the token endpoint and might help if that’s the cause.
If there is an upgrade for libcurl 4 (I believe it’s a dev package), it may be worth while upgrading and testing that, but sticking with mono 4.2.3 would be best since 4.4 and 4.6 seems to have different issues.
Another thing to add is that similar happens when using RARBG as a provider in Jackett. Jackett just hangs, the page doesn’t load and nothing updates until the daemon is restarted (and it hangs again eventually). Definitely looks like something strange in the underlying libraries and with RARBG.
I’m using libcurl3 release 7.47.0-1ubuntu2.1 on Ubuntu 16.04. I can see the following libcurl4 packages - libcurl4-doc, libcurl4-gnutls-dev, libcurl4-nss-dev, libcurl4-openssl-dev. Which do I install and do I need to do anything to enable it within mono? (or does it override/replace v3 automatically?)
I believe it’s libcurl4-openssl-dev that Sonarr will fallback to if it can’t connect via SSL to the server, but only if it can’t f you connect using native mono libraries. It may be using v3 of libcurl if that package isn’t installed.
If it’s installed it already is, looks like Sonarr relies on v4, not v3 and I’m pretty sure Sonarr can’t connect to RARBG unless it uses the libcurl fallback. Restarting Sonarr with trace logging enabled will check and if Sonarr is able to fallback to it.