RADARR sees indexers but not SAB


27 posts in this topic Last Reply

Recommended Posts

Hello, I hope you can help. I have had Radarr and Sonarr running fine for a long time, but now they are unable to contact Sabnzbd.

They are on the same 10.1.10.224 server. Just different ports.

They both see the Internet indexers.

I have started up couchpotato and SickChill (my previous Apps) and they can use Sabnzbd fine.

What am I missing here.

Please help guide my fault finding. Its driving me crazy.

backup-diagnostics-20200116-1822.zip

Link to post

Hi, I see this error, http://10.1.10.224:8080/api?mode=history&start=0&limit=30&category=movies&apikey=(removed)&output=json: 503.ServiceUnavailable.

 

I cut and pasted the link with the API and it gets a response.

 

Radarr front end fails with, "Test was aborted due to an error: Unable to connect to SABnzbd, please check your settings"

 

Setup is simple:

IP address

Port 8080

API key (cut and paste)

No user name or password

No SSL.

Edited by BigBirdie
Link to post

Here is the error log:

 

2020-01-17 21:16:09,283 DEBG 'radarr' stdout output:
[Error] Sabnzbd: Unable to connect to SABnzbd, please check your settings

[v0.2.0.1450] NzbDrone.Core.Download.Clients.DownloadClientException: Unable to connect to SABnzbd, please check your settings ---> NzbDrone.Common.Http.HttpException: HTTP request failed: [503:ServiceUnavailable] [GET] at [http://10.1.10.224:8080/api?mode=version&apikey=c9276381d4d257559556dbef38565f03&output=json]
at NzbDrone.Common.Http.HttpClient.Execute (NzbDrone.Common.Http.HttpRequest request) [0x00131] in C:\projects\radarr-usby1\src\NzbDrone.Common\Http\HttpClient.cs:100
at NzbDrone.Core.Download.Clients.Sabnzbd.SabnzbdProxy.ProcessRequest (NzbDrone.Common.Http.HttpRequestBuilder requestBuilder, NzbDrone.Core.Download.Clients.Sabnzbd.SabnzbdSettings settings) [0x0001d] in C:\projects\radarr-usby1\src\NzbDrone.Core\Download\Clients\Sabnzbd\SabnzbdProxy.cs:184
--- End of inner exception stack trace ---
at NzbDrone.Core.Download.Clients.Sabnzbd.SabnzbdProxy.ProcessRequest (NzbDrone.Common.Http.HttpRequestBuilder requestBuilder, NzbDrone.Core.Download.Clients.Sabnzbd.SabnzbdSettings settings) [0x0002d] in C:\projects\radarr-usby1\src\NzbDrone.Core\Download\Clients\Sabnzbd\SabnzbdProxy.cs:188
at NzbDrone.Core.Download.Clients.Sabnzbd.SabnzbdProxy.GetVersion (NzbDrone.Core.Download.Clients.Sabnzbd.SabnzbdSettings settings) [0x0000d] in C:\projects\radarr-usby1\src\NzbDrone.Core\Download\Clients\Sabnzbd\SabnzbdProxy.cs:80
at NzbDrone.Core.Download.Clients.Sabnzbd.Sabnzbd.TestConnectionAndVersion () [0x00000] in C:\projects\radarr-usby1\src\NzbDrone.Core\Download\Clients\Sabnzbd\Sabnzbd.cs:359
 

Link to post
  • 1 year later...

I figured out my issue, but its strange that it popped up today, and the resolution wasn't what I expected.

 

I normally follow Space Invader One's videos for setting dockers up rather than reinventing the wheel.  That's what I did with SABnzbd, Radarr and Sonarr.

This morning the issue I was having was that Sonarr and Radarr couldn't communicate with SABnzbd.  They've been working for over a year, without issue.  Yesterday I lost all my dockers and had to restore from a backup, so somehow that might be part of what caused the issue - not sure.

To resolve, I noticed that when I looked at "Status and Interface Options" in the SABnzbd UI, the local IPV4 address was a 10.8.x.x address.  I had this set as the 192.168.1.x address of my server in Radarr and Sonarr (and I'm sure this is how it has always been!).  I copied/pasted the 10.x.x.x address into the SAB config in Sonarr and Radarr, and lo and behold, they were able to connect and started to work...

 

Not sure how this happened, but glad it is...

Link to post

I am hoping this gets update. I am having a similar issue. I updated Sonarr last night to version 3.0.4.1131. Radarr works absolutely fin but Sonarr cannot contact any of my download clients. I use Deluge and SABNzb. For SAB I receive the following error in the log file.

 

[v3.0.4.1131] NzbDrone.Core.Download.Clients.DownloadClientException: Unable to connect to SABnzbd, HTTP request failed: [503:ServiceUnavailable] [GET] at [http://IP Address:8080/api?mode=get_config&apikey=70919fa08ab1429cb0bb0d03cf4357e5&output=json] ---> NzbDrone.Common.Http.HttpException: HTTP request failed: [503:ServiceUnavailable] [GET] at [http://IP Address:8080/api?mode=get_config&apikey=70919fa08ab1429cb0bb0d03cf4357e5&output=json]

 

I have verified the API keys etc and all are fine. Like I said Radarr is working flawlessly. 

Link to post

All,

I'm having the same issue. All dockers set up as proxynet with ports forwarded. This has been running great for over a year. Now I cant access either of my download clients from sonarr or radarr. I can access both deluge and SABnzbd from the web but neither are reached by sonarr or radarr. Radarr says Unable to communicate with DelugeVPN. The operation has timed out.: 'http://192.168.1.2:8112/json' Sonarr says the same.  Saonnar says, Test was aborted due to an error: Unable to connect to SABnzbd, HTTP request failed: [503:ServiceUnavailable] [GET] at [http://192.168.1.2:8050/api?mode=get_config&apikey=xxxxxxxxxxxxxxxxxxxxxx&output=json] Radarr says the same here as well.

 

Help Please

Link to post
On 2/26/2021 at 11:33 AM, brawny said:

To resolve, I noticed that when I looked at "Status and Interface Options" in the SABnzbd UI, the local IPV4 address was a 10.8.x.x address.  I had this set as the 192.168.1.x address of my server in Radarr and Sonarr (and I'm sure this is how it has always been!).  I copied/pasted the 10.x.x.x address into the SAB config in Sonarr and Radarr, and lo and behold, they were able to connect and started to work...

 

Not sure how this happened, but glad it is...

See if this works for you. For some reason the IP address SAB was using internally changed for me. Not something I did myself...  The quote above is how I found and resolved it. 

Edited by brawny
Spelling
Link to post

brawny,

thanks for the info, but that doesn't seem to help for me, I'm running radarr, sonarr and sabnzbd in dockers using proxynet.

sabnzbd shows local as 172.18.0.4 for the past 2 years sonarr and radarr have used 192.168.1.2.

Not sure what changed.

thanks tho

Chas

Screenshot 2021-02-28 121101.jpg

Screenshot 2021-02-28 121250.jpg

Link to post

Ok I think I tracked the problem down.

 

it appears it is related to deluge VPN as I am using VPN proxy on my radar and sonar.

 

disabling the reverse proxy restores it back to working.

 

im gonna play around with adding additional ports in deluge vpn and see if that fixes it

 

for now though off to work, it’ll have to wait.

Link to post
On 2/26/2021 at 11:33 AM, brawny said:

To resolve, I noticed that when I looked at "Status and Interface Options" in the SABnzbd UI, the local IPV4 address was a 10.8.x.x address.  I had this set as the 192.168.1.x address of my server in Radarr and Sonarr (and I'm sure this is how it has always been!).  I copied/pasted the 10.x.x.x address into the SAB config in Sonarr and Radarr, and lo and behold, they were able to connect and started to work...

 

Not sure how this happened, but glad it is...

 

I'm not sure why this has happened as well. Everything was working and suddenly something changed and I started getting 503 errors. All of my *arr containers could no longer connect with qBittorrent, plus, all of the indexers that I set up failed. By using the 172.*.*.* ip of the container in qBit, I am now able to connect, but how do you change the address in Jackett? Do I have to manually change the url of each indexer to update it to the 172.*.*.* address?

Link to post
17 minutes ago, Ao27893 said:

 

I guess it finally caught up to all of us.

 

9 minutes ago, bmoney003 said:

im having the same issues with radarr and nzbget and deluge.  will not connect.  this is as of friday as well.  

 

Here are the answers from the faq:

 

Quote

Q25. I have recently updated my Docker image for DelugeVPN/PrivoxyVPN/SABnzbdVPN/qBittorrentVPN and can no view the Web UI for the application i am routing through the VPN container, why is this and how can i fix it?.
 

A25. Due to iptables tightening it is now a requirement that you add the Web UI/API ports for the application you want to route through the VPN to the 'ADDITIONAL_PORTS' env var value for the VPN container, if you have multiple ports then please separate the values with a comma, e.g. 'ADDITIONAL_PORTS' = 1234,5678

The other change you will need to do is when defining connections from an application to another application in the same container network (as is the case in this scenario) then you will need to set the host to 'localhost' and NOT the LAN IP address, this is because the applications are now bound to the same network and thus should communicate over 'localhost'.

Please also review A24. above, and ensure you have completed ALL steps to route a container through another one.
 

Q26. I have recently updated my Docker image for DelugeVPN/PrivoxyVPN/SABnzbdVPN/qBittorrentVPN and have setup Sonarr/Radarr/Lidarr...etc to use Privoxy (proxy server), but this is now no longer able to connect to the 'Download Client' (e.g. Deluge, rTorrent, qBittorrent, SABnzbd), why is this and how can i fix it?.
 

A26. Due to iptables tightening you need to now bypass local addresses for proxy connection in index applications, for Sonarr/Radarr/Lidarr this can be achieved by editing the value for 'Ignored Addresses' under the Settings/General/Proxy and entering in the IP address of the unRAID server running the VPN container. This will then bypass using Privoxy (proxy server) for connections to the local server, and thus allow a direct connection to the download client.

An alternative method to this is to setup Jackett, then configure Jackett to use Privoxy. You then simply point Sonarr/Radarr/Lidarr...etc at Jackett as an 'Indexer' and you are done, there is NO need to configure a proxy for Sonarr/Radarr/Lidarr...etc in this configuration, as Jackett is already doing the proxying for you.

 

Link to post

...Aaand the fix has stopped working! qBit and the indexers are no longer connecting for me again. I changed qBit back to my original host ip address and it connected right away. I don't know what's going on.

Link to post
On 2/26/2021 at 8:33 AM, brawny said:

I figured out my issue, but its strange that it popped up today, and the resolution wasn't what I expected.

 

I normally follow Space Invader One's videos for setting dockers up rather than reinventing the wheel.  That's what I did with SABnzbd, Radarr and Sonarr.

This morning the issue I was having was that Sonarr and Radarr couldn't communicate with SABnzbd.  They've been working for over a year, without issue.  Yesterday I lost all my dockers and had to restore from a backup, so somehow that might be part of what caused the issue - not sure.

To resolve, I noticed that when I looked at "Status and Interface Options" in the SABnzbd UI, the local IPV4 address was a 10.8.x.x address.  I had this set as the 192.168.1.x address of my server in Radarr and Sonarr (and I'm sure this is how it has always been!).  I copied/pasted the 10.x.x.x address into the SAB config in Sonarr and Radarr, and lo and behold, they were able to connect and started to work...

 

Not sure how this happened, but glad it is...

Thank you! Would not have been able to figure it out without this post!

Link to post
Quote

A26. Due to iptables tightening you need to now bypass local addresses for proxy connection in index applications, for Sonarr/Radarr/Lidarr this can be achieved by editing the value for 'Ignored Addresses' under the Settings/General/Proxy and entering in the IP address of the unRAID server running the VPN container. This will then bypass using Privoxy (proxy server) for connections to the local server, and thus allow a direct connection to the download client.

 Does this still allow Sonarr/Radarr/Lidarr to route though privoxy? If so how can I tell?

Link to post
Posted (edited)

A26 fixed my issues. I restored Radarr and Sonarr to be bridge and not use binhex-privoxy nextwork setting for the containers.

I then edited the Radarr and Sonarr general field, within the Radarr and Sonarr appls, not the docker, and ticked "Bypass proxy for local addresses", and added my network address range into the "Ignored Addresses", field.

All good again.

 

image.png.1924a5aa60e79278bcf266fece62dc86.png

 

Not sure how to test it is getting a VPN address or not.

I know I had problems with the blacklist, blocking Sonarr and Radarr, so I reverted to old copies of the files and it it started up again.

 

 

Does anyone know if you should be able to open the GUI for BINHEX-PRIVOXY App?

I get an error when I try, "Privoxy is not being used", but it is. 

I have a headless server so am trying to access from a local pc web browser.

Thanks for the help!

Edited by BigBirdie
Fixed typos, added a bit more detail.
Link to post
  • 2 weeks later...
On 3/9/2021 at 6:19 AM, El Player said:

 Does this still allow Sonarr/Radarr/Lidarr to route though privoxy? If so how can I tell?

No, as far as I can tell no it does not. After entering your UnRaid IP into the ignored field after testing that they connect to sab successfully I then open up a console from the Sonar/Radar docker containers and using this command 

$ curl ifconfig.io

reveals your public ip address. Sab is still behind the proxy tho.

 

UPDATE - This worked for Radarr only, when I tried adding the ports for Sonarr my sab container failed and radarr and sonarr got stuck in a constant rebuild loop, my sab container turned into an orphan image, I resolved this by re installing the docker image for sabnzbvpn and re added all the settings, ports etc started working apart from connecting to sab

Ive worked it out. The steps I have taken are:

1. For Radarr, unticked use proxy in the general settings.

2. Followed steps from A24 from posted doc https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

3. Made sure that the port was added under ADDITIONAL_PORTS as well as adding the port using the add another path, port...etc (so it appears twice in the config)

4. Using the add another path, port etc selected config type variable under key create VPN_OUTPUT_PORTS with the vpn container port number which would be your sabnzb port as the value. Then create another variable type of VPN_INPUT_PORTS with value as the port number of the application you want to access so Radarrs default web ui port.

4. Made sure the vpn container starts first.

5. Tested using curl ifconfig.io on console. Also you can only access the ui by typing in ip:port in address bar as no webui link will appear in Unraid anymore.

6. Make sure to check your LAN_NETWORK ip range. it might of reverted back to default and need updating.

 

All working now same applies to any of the *arrs

Edited by DioxideC
Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.