Closed Seishirou101 closed 3 years ago
I have just updated using the :latest tag and I have confirmed that sonarr and radarr connect fine with no issues.
What happens within Sonarr/Radarr when you click the test button? If it shows an "x" (says failed) then look at Sonarr/Radarr logs and see what it shows.
it said failed to connect host:port/json
What does your download client config look in Sonarr/Radarr? Here is mine:
It looks the same but with host ip different. As the original post, the same config is used between the two image versions and above though I haven't tested since making the post as it is sitting at version 2.0.4.dev38_g23a48dd01-2-13 so I can connect.
I have the same issue. linuxserver/sonarr and linuxserver/radarr are not able to connect after updating this docker to the latest. Get "Unable to communicate with deluge. The operation has timed out.: 'http://hostip:8112/json'". Looking at the log, this is what I am finding in the logs:
[v2.0.0.5344] System.Net.WebException: The operation has timed out.: 'http://hostip:8112/json' ---> System.Net.WebException: The operation has timed out.
at System.Net.HttpWebRequest.RunWithTimeoutWorker[T] (System.Threading.Tasks.Task1[TResult] workerTask, System.Int32 timeout, System.Action abort, System.Func
1[TResult] aborted, System.Threading.CancellationTokenSource cts) [0x000f8] in <91935ad653254a93b9d73a9f8f2f7a2d>:0
at System.Net.HttpWebRequest.GetResponse () [0x00016] in <91935ad653254a93b9d73a9f8f2f7a2d>:0
at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x0011b] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\Dispatchers\ManagedHttpDispatcher.cs:82
--- End of inner exception stack trace ---
at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x001ca] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\Dispatchers\ManagedHttpDispatcher.cs:113
at NzbDrone.Common.Http.Dispatchers.FallbackHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x000b5] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\Dispatchers\FallbackHttpDispatcher.cs:53
at NzbDrone.Common.Http.HttpClient.ExecuteRequest (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookieContainer) [0x0007e] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\HttpClient.cs:121
at NzbDrone.Common.Http.HttpClient.Execute (NzbDrone.Common.Http.HttpRequest request) [0x00008] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Http\HttpClient.cs:57
at NzbDrone.Core.Download.Clients.Deluge.DelugeProxy.AuthenticateClient (NzbDrone.Common.Http.JsonRpcRequestBuilder requestBuilder, NzbDrone.Core.Download.Clients.Deluge.DelugeSettings settings, System.Boolean reauthenticate) [0x0005b] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Core\Download\Clients\Deluge\DelugeProxy.cs:290
at NzbDrone.Core.Download.Clients.Deluge.DelugeProxy.BuildRequest (NzbDrone.Core.Download.Clients.Deluge.DelugeSettings settings) [0x0006d] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Core\Download\Clients\Deluge\DelugeProxy.cs:203
at NzbDrone.Core.Download.Clients.Deluge.DelugeProxy.ProcessRequest[TResult] (NzbDrone.Core.Download.Clients.Deluge.DelugeSettings settings, System.String method, System.Object[] arguments) [0x00000] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Core\Download\Clients\Deluge\DelugeProxy.cs:210
at NzbDrone.Core.Download.Clients.Deluge.DelugeProxy.GetTorrentsByLabel (System.String label, NzbDrone.Core.Download.Clients.Deluge.DelugeSettings settings) [0x00012] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Core\Download\Clients\Deluge\DelugeProxy.cs:96
at NzbDrone.Core.Download.Clients.Deluge.Deluge.GetItems () [0x00012] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Core\Download\Clients\Deluge\Deluge.cs:96
at NzbDrone.Core.Download.TrackedDownloads.DownloadMonitoringService.ProcessClientDownloads (NzbDrone.Core.Download.IDownloadClient downloadClient) [0x0000c] in C:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Core\Download\TrackedDownloads\DownloadMonitoringService.cs:89
Nothing has changed besides this docker and I can roll it back and it is fine.
Same connectivity issues beyond _2.0.4.dev38g23a48dd01-3-01 in my testing, 3-01 works fine but moving to later or the latest build gives me the same error @huff02 posted. radarr/sonarr are configured using the host IP rather than the docker IP... (the IP assigned to unRaid by my firewall).
@Seishirou101 - which IP are you specifying? docker IP or server (host) IP? Also, are you using a custom docker network? I am using proxynet, as depicted in SpaceInvader's video on how to setup letsencrypt/swag with a reverse proxy. I also have the 172.18.0.0/16 proxynet subnet specified in the LAN_NETWORK container variable.
most probably related to this:- https://github.com/binhex/arch-delugevpn/issues/272
I completely forgot I opened this issue after the issue went stale. Strangely I was not notified of huff02's comment on top of that, the issue disappeared for me without changing anything... I do not remember when I switched back to the latest tag, but currently running image ID f146ab88b410 and it is still working.
@groot-stuff the IP I have specified is the server (host) IP, and I am not running a custom docker network, but I did specify a docker network and did not let docker create one on its own for this container.
I will leave the issue up even though I no longer have the issue, since others do. Hopefully what binhex specified fixes it for y'all.
Confirming this was related to #272 for me. Following A24 in the VPN FAQ resolved it and binhex-delugevpn:latest
is working as expected (radarr/sonarr can connect to deluge download client).
I outlined the changes I made below for reference... along with a couple questions. Feeling like this issue can be closed out now (but please :) answer my 3 questions).
updated radarr/sonarr container network configs as outlined in A24 (adding --net=container:binhex-delugevpn
to Extra Parameters, changing Network Type to None and unspecifying port configurations)
added VPN_INPUT_PORTS
and VPN_OUTPUT_PORTS
variables to my binhex-delugevpn config/template manually (via GUI)
ADDITIONAL_PORTS
now deprecated? If so, should any ports previously specified there be specified in VPN_INPUT_PORTS
?added port configurations in binhex-delugevpn config/template for radarr/sonarr ports
specified those ports in the VPN_INPUT_PORTS
variable added in # 2
LAN_NETWORK
variable, this isn't necessary... I think I added it when trying to resolve the issue last time.updated swag/nginx reverse proxy configs for radarr/sonarr subdomains to point to binhex-delugevpn container
updated radarr/sonarr deluge download client settings to use localhost (as noted in A24 Notes section, # 1)
I was going to update General > Proxy in radarr/sonarr to use localhost, but...
--net=container:binhex-delugevpn
(as per A24)?
- Is there a way to pull down updated templates within unRaid, rather than checking changes to delugevpn.xml in github and aligning changes manually via unRaid's GUI? I suppose pulling down an updated template would overwrite the entire xml file, wiping my setup... ehh?
yes, you can do this but you would need to delete your old template with all your configuration, then go to CA and re-download the template and re-configure again, sadly there is no mechanism in unraid to update existing templates for users who already have the template on disk.
Is ADDITIONAL_PORTS now deprecated? If so, should any ports previously specified there be specified in VPN_INPUT_PORTS?
yes it is, please delete the env var and put any ports defined in there into VPN_INPUT_PORTS
Am I correct - that specifying a proxy within radarr/sonarr isn't necessary now that I am properly routing those containers through the binhex-delugevpn container with --net=container:binhex-delugevpn (as per A24)?
yes correct, a proxy is not necessary (and probably will cause issues) if you are routing the container through one of the vpn containers.
Thanks for the details as I also cannot connect to delugevpn. Following the your lead when I implement your settings listed:
ok never mind...reset everything back to defaults and now im connecting ...thanks
when updating to latest for the docker image, sonarr/radarr is no longer able to connect. going back to 2.0.4.dev38_g23a48dd01-2-13, the problem is no longer apparent and going up to 2.0.4.dev38_g23a48dd01-2-14 has the problem occur again.