The port settings in the delugevpn container are automatically set by binhex's code (check supervisord log to see the magic happening) - you don't need to set them. Incoming port is the important one from a port forwarding perspective, you're likely to see this change when you restart the container. Outgoing doesn't matter so much

 

(for some reason mine has just jumped from seeding around 0.1Kbit/s to 250Kbit/s so I have no idea what's going on

I see the incoming port in the Web gui for Deluge changes itself after whatever I set it to on a restart of deluge, must be that.

 

Tried airVPN and that's banging away at 9MB/s now, guess it could be the combination of PIA and Virgin. 

Edited April 25, 20197 yr by Chamzamzoo

Since the latest (today) update, privoxy is failing to start. Here is the relevant log section:

[info] All checks complete, starting Privoxy...
2019-05-01T21:53:29.956623500Z 
2019-05-01 21:53:29,957 DEBG 'privoxy-script' stderr output:
2019-05-01 21:53:29.957 7f0eef6eb140 Info: Privoxy version 3.0.28
2019-05-01 21:53:29.957 7f0eef6eb140 Info: Program name: /usr/bin/privoxy
2019-05-01T21:53:29.957904700Z 
2019-05-01 21:53:30,007 DEBG 'privoxy-script' stderr output:
2019-05-01 21:53:30.006 7f0eef6eb140 Fatal error: can't bind to 172.17.0.4 :8118: The hostname is not resolvable
2019-05-01T21:53:30.007208000Z 
2019-05-01 21:53:30,007 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 139932369015472 for <Subprocess at 139932368914976 with name privoxy-script in state RUNNING> (stdout)>
2019-05-01 21:53:30,007 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 139932368390128 for <Subprocess at 139932368914976 with name privoxy-script in state RUNNING> (stderr)>
2019-05-01 21:53:30,008 INFO exited: privoxy-script (exit status 1; not expected)
2019-05-01 21:53:30,008 DEBG received SIGCHLD indicating a child quit
2019-05-01 21:53:30,231 DEBG 'start-script' stdout output:
[info] Successfully retrieved external IP address 172.98.67.33

No changes in the startup or otherwise -- it was working fine last night after the latest Docker update, right up until watchtower updated to the latest 2 hour old version.

 

Rolling back to the build from 3 months ago resolved the problem and restored network connection.

Edited May 1, 20197 yr by kae
rollback information

I'm having the same exact issue as @kae since updating this evening. 

2019-05-01 22:01:36.491 147783352140 Fatal error: can't bind to 172.17.0.2 :8118: The hostname is not resolvable

 

Updated Delugevpn container this evening and the proxy stopped working for Sonarr and Radarr.

I'm seeing the same issue with the proxy after updating:

 

2019-05-02 06:20:11.702 7fd4b2246140 Fatal error: can't bind to 172.17.0.2 :8118: The hostname is not resolvable

 

Yup, I'm getting the same 'hostname is not resolvable' error as of today too. Think I might stop Ouroboros from watching delugevpn in future! Afterall, if it ain't broke...

looking into it, for now stop the container then delete the folder /config/privoxy then start the container again, that should get you working for now.

47 minutes ago, binhex said:

looking into it, for now stop the container then delete the folder /config/privoxy then start the container again, that should get you working for now.

Didn't work for me. Sonarr immediately gives me the following Error Message.

 

"Proxy Health Check failed: Error getting response stream (ReadDoneAsync2): ReceiveFailure: 'http://services.sonarr.tv/v1/ping'"

28 minutes ago, ceb0610 said:

Didn't work for me. Sonarr immediately gives me the following Error Message.

 

"Proxy Health Check failed: Error getting response stream (ReadDoneAsync2): ReceiveFailure: 'http://services.sonarr.tv/v1/ping'"

Same thing for me. I renamed the /config/privoxy folder and restarted container. It created a new folder, but still didn't fix the issue.

34 minutes ago, ceb0610 said:

Didn't work for me. Sonarr immediately gives me the following Error Message.

 

"Proxy Health Check failed: Error getting response stream (ReadDoneAsync2): ReceiveFailure: 'http://services.sonarr.tv/v1/ping'"

Same here.

2 hours ago, binhex said:

looking into it, for now stop the container then delete the folder /config/privoxy then start the container again, that should get you working for now.

Seeing the same issue as everyone else. This solution did not solve the problem.

new image built please pull down and see if this resolves the privoxy issue.

working for me now - thank you!

New image resolved the issue! for me. Thanks!

23 minutes ago, binhex said:

new image built please pull down and see if this resolves the privoxy issue.

Worked. Thanks for the speedy rebuild.

1 hour ago, binhex said:

new image built please pull down and see if this resolves the privoxy issue.

Thank you Bin!  Looks like plenty of confirmation of resolution already on the thread but I will also pull down and test this evening.

Worked great! Thanks for your help.

4 hours ago, binhex said:

new image built please pull down and see if this resolves the privoxy issue.

Thank you so much! This also worked for me.

Hi binhex:

 

Sadly, I have been having issues getting DelugeVPN to work properly in recent days. The container refuses to download anything for more than 5 mins at a  time, before I have to restart it. Now, the downloads don't even start, they just hang at 0.0 KB/s Over the past few days, I have also seen an error message regarding port 8112 already being in use:

2019-05-03 16:04:15,009 DEBG 'watchdog-script' stdout output:
[info] Starting Deluge Web UI...
[info] Deluge Web UI started
[debug] VPN incoming port is 37858
[debug] Deluge incoming port is 37858
[debug] VPN IP is 10.29.11.6
[debug] Deluge IP is 10.29.11.6

2019-05-03 16:04:20,674 DEBG 'watchdog-script' stderr output:
Traceback (most recent call last):
  File "/usr/bin/deluge-web", line 11, in <module>
    load_entry_point('deluge==1.3.15', 'console_scripts', 'deluge-web')()
  File "/usr/lib/python2.7/site-packages/deluge/ui/web/web.py", line 144, in start

2019-05-03 16:04:20,674 DEBG 'watchdog-script' stderr output:
    web.start()
  File "/usr/lib/python2.7/site-packages/deluge/ui/web/web.py", line 131, in start
    self.server.start()
  File "/usr/lib/python2.7/site-packages/deluge/ui/web/server.py", line 670, in start

2019-05-03 16:04:20,677 DEBG 'watchdog-script' stderr output:
    self.start_normal()
  File "/usr/lib/python2.7/site-packages/deluge/ui/web/server.py", line 678, in start_normal

2019-05-03 16:04:20,677 DEBG 'watchdog-script' stderr output:
    self.socket = reactor.listenTCP(self.port, self.site, interface=self.interface)
  File "/usr/lib/python2.7/site-packages/twisted/internet/posixbase.py", line 495, in listenTCP

2019-05-03 16:04:20,717 DEBG 'watchdog-script' stderr output:
    p.startListening()
  File "/usr/lib/python2.7/site-packages/twisted/internet/tcp.py", line 1363, in startListening

2019-05-03 16:04:20,747 DEBG 'watchdog-script' stderr output:
    raise CannotListenError(self.interface, self.port, le)
twisted.internet.error.CannotListenError: Couldn't listen on 0.0.0.0:8112: [Errno 98] Address already in use.

Upon investigation, the delugevpn container seems to be the only use of port 8112. No other Deluge containers are running. 

 

Please see attached for redacted versions of my full supervisord log (debug) and docker-compose.yml, with usernames/passwords removed. I have also included my deluge core.conf for your perusal. Please let me know if you need anything else. I look forward to your reply.

 

Thanks for your time,

~ happinessattack

core.conf supervisord-redacted.log docker-compose-redacted.yml

Hi there, I am completely new to just about everything associated with unRaid and the Docker system so I am probably just having a fundamental misunderstanding about how this stuff works, but I am noticing something weird nonetheless. I got everything up and running with my PIA account linked to deluge and everything seems to work okay from the unraid/deluge side of things, but when deluge is running it is somehow maxing out my upload connection even though nothing is actually being uploaded. It seems to be tied to the download rate, for example, if I limit deluge to 5MB/s down, then the upload sits around the same speed. It does this all the way until it reaches the limit at around 8MB/s up, so when I am running full bandwidth downloading my upload is constantly capped.

 

Is there something I am completely misunderstanding about my setup or is there something really weird going on here?

 

Thanks for your time.

3 hours ago, Civrock said:

it is somehow maxing out my upload connection even though nothing is actually being uploaded.

Is Deluge really showing no active torrents? My guess is that you are seeding. You can configure the bandwidth used for this in the app settings.

Edited May 4, 20197 yr by wgstarks

10 hours ago, wgstarks said:

Is Deluge really showing no active torrents? My guess is that you are seeding. You can configure the bandwidth used for this in the app settings.

It is showing active torrents, but most of them don't have anything going on in the "Up Speed" column and their "Uploaded" stat is extremely small, most showing less than 50MB uploaded compared to the many tens of GB downloaded. There are sporadic uploads at varying times, but nothing sustained and nothing large enough to cap out my transfer bandwidth.

 

When I go into the preferences to set global and per-torrent seed caps of zero or anything else it is still going full tilt on the transfer rate measured at my Edgerouter.

 

Edit: What are the chances / is it even possible that I have something configured improperly and instead of writing directly to disc, my server is sending all that data across the network back to itself to write to the array? When the array is writing at full speed the transfer rate is maxed and when the array is writing at a slow speed, the internet transfer is around the same speed. Sounds insane, and I am not even sure it is possible. But bandwidth seems to be increasing / decreasing with array write speed. That really doesn't make a whole lot of sense.

Edited May 4, 20197 yr by Civrock

Just to tie up my support -- working again. Thanks for the quick fix!

Is it possible to change the deluge daemon port? I have tried changing the values in the core.conf, web.conf, and hostlist contained in the config folder. If it's possible, I'd appreciate any pointers.