Unable to communicate with download client The request timed out

Help & Support
#1

I seem to be getting this error in the System>Health quite often. The wiki link accompanying the error points to github but no information is offered.

I am using both sabnzbd and deluge and they seem to test ok. I’m not sure if this is particular to my setup as I’m running sonarr in a docker.

Log: http://pastebin.com/pRYbXTYv

Thanks

#2

Its probably Deluge (their Web API Is pretty bad), but that looks like an old version you’re running.

Make sure Sonarr is up to date on the develop branch (the torrents branch is dead), mono is 3.6 and that you’re running mono with the --debug switch.

If you’re still having issues after that please post a new log and the versions of Sonarr and mono that you are running.

#3

Thanks markus. Yep, running the develop branch. I just haven’t been running mono with the debug, will turn it on and post a new log.

Current version of deluge 1.3.11.
Sonarr:

Version 2.0.0.2407
Mono Version 3.6.0 (tarball Wed Aug 13 07:45:56 UTC 2014)
AppData directory /root/.config/NzbDrone
Startup directory /opt/NzbDrone
#4

Markus, I enabled --debug and I’m noticing a lot of Deluge related connection errors.

http://pastebin.com/Uy3fmw7e

Thoughts?

#5

Its something in the response from Deluge that Sonarr isn’t handling.

Which version of Deluge?
If you enable trace logging the response from Deluge should be logged (so we can dig in further).

Doesn’t look like mono is running with --debug as there are no line numbers in the stack trace.

at NzbDrone.Core.Download.Clients.Deluge.Deluge.GetItems () [0x00000] in <filename unknown>:0 should have a file name and line number.

#6

I assumed the --debug switch came after the NzbDrone.exe not the mono in the command, my mistake. I will post another log when it happens again. For some reason, this seems to happen only in the night/early morning. Could be my setup. As I do have a cron job the resets my vpn connection and consequent restart the deluge process. That could have something to do with it.

Another question, I noticed that couchpotato uses Deluge’s daemon port (58846), not the web port (8112) as sonarr. Just wondering, as I tried to enter the daemon port in sonarr and it doesn’t seem to work. Just curious.

#7

Yeah, because the web port is pretty bad (there are quite a few issues).

Its something we’ve talked about using, just haven’t taken the plunge.

#8

Markus, here’s another log with the error: http://pastebin.com/YFmcbhv9

I’m convinced this happens because I reset my vpn connection along with deluge/deluge-web services in the morning and for some reason sonarr produces the error message.

#9

Need trace logging on in Sonarr to see what the response from Deluge is (since it seems to return something, but not whats expected.

#10

Hopefully there’s more info in this log.

#11

This log doesn’t actually show any issues, I’d expect to see: 14-12-13 05:06:29.2|Warn|DownloadTrackingService|Unable to retrieve queue and history items from Deluge (with a different time stamp).

#12

You’re right, my apologies…

This log has the error.

#13

Looks like Deluge returns null instead of a list of torrents, but its getting a response, I have added a check to prevent it from erroring out, but it will treat it like no torrents were returned.

I suspect the issue is due to the Deluge Web front end not being able to connect to the daemon, but I’m not sure why (not the first time I’ve heard of issues with Deluge).

#14