[Support] binhex - Deluge

[binhex]

 
The config is pointing to the right parth - 

Ok and I assume none of your missing data is found in that path is this correct? If this is the case then I can only assume file system corruption of some manner if you have a backup of your app data then I would suggest a restore.

Sent from my 22021211RG using Tapatalk

[z0ki]

23 hours ago, binhex said:

Ok and I assume none of your missing data is found in that path is this correct? If this is the case then I can only assume file system corruption of some manner if you have a backup of your app data then I would suggest a restore.

Sent from my 22021211RG using Tapatalk
 

 

All data is in that path. I downloaded your delugeVPN version, and everything is working. Something is up with the none VPN Binhex Deluge version that was recently updated. Like i mentioned even trying to add paths in preferences and clicking apply and ok nothing happens. Happy to take a video for you if you like.

Edited May 8, 2023 by z0ki

[binhex]

13 hours ago, z0ki said:

even trying to add paths in preferences and clicking apply and ok nothing happens

Sorry, i'm unable to reproduce this, i have just pulled down the latest deluge image, changed the paths for completed, incomplete and torrents clicked ok, went back into preferred and the paths are still set, restarted the container, check preferences and the paths are still set correctly, so unless you can give me steps to reproduce this then i cannot fix it.

 

Please keep in mind i have literally millions of downloads of this image, if there was an issue with the image i would expect more than 1 person complaining, i suspect there is something going on here that is local to your setup,

Try resetting permissions by deleting /config/perms.txt then restart the container and try setting paths again.

[Chriexpe]

For some odd reason Deluge isn't saving any config, if I restart the docker/server it rolls back to default (any setting, for ex: Queue and Bandwidth).

The permissions on Appdata are drwxrwxrwx, so it might be something else.

I only use the ItConfig plugin (I needed to put it into web.conf otherwise it dissapeared) and that dark theme mod from Joelacus.

Also is there a way to permanently remove/add new columns?

Edited June 16, 2023 by Chriexpe

[node]

binhex-deluge has recently "stopped working" for me every 24 hours or so. By that I mean my the daemon appears offline to my Windows Deluge client and the webUI doesn't load - both work after a container restart. I don't know a way to check if it's still seeding or partially still running in some manner, but the container hasn't stopped according to the Unraid UI. The last four lines of the supervisord.log are consistently something like this when this happens:

 

2023-07-22 16:30:55,639 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22770150224528 for <Subprocess at 22770134306832 with name deluge-script in state RUNNING> (stdout)>
2023-07-22 16:30:55,658 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22770149763984 for <Subprocess at 22770134306832 with name deluge-script in state RUNNING> (stderr)>
2023-07-22 16:30:55,682 INFO exited: deluge-script (exit status 0; expected)
2023-07-22 16:30:55,688 DEBG received SIGCHLD indicating a child quit

 

From searching here and other places, I've so far tried:

 

- Switching from the nordlynx container to Gluetun for nordvpn wireguard as some comments said it could be VPN related.

- Removing a reference  to user0/download that I previously added in the container config in case that was messing with things

- Deleted perms.txt and let it rebuild.

 

Any help resolving this appreciated - I COULD just create a userscript to reboot the container nightly, but it seems wiser to solve it properly.

 

[Myleslewis]

On 7/23/2023 at 11:27 AM, node said:

binhex-deluge has recently "stopped working" for me every 24 hours or so. By that I mean my the daemon appears offline to my Windows Deluge client and the webUI doesn't load - both work after a container restart. I don't know a way to check if it's still seeding or partially still running in some manner, but the container hasn't stopped according to the Unraid UI. The last four lines of the supervisord.log are consistently something like this when this happens:

 

2023-07-22 16:30:55,639 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22770150224528 for <Subprocess at 22770134306832 with name deluge-script in state RUNNING> (stdout)>
2023-07-22 16:30:55,658 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22770149763984 for <Subprocess at 22770134306832 with name deluge-script in state RUNNING> (stderr)>
2023-07-22 16:30:55,682 INFO exited: deluge-script (exit status 0; expected)
2023-07-22 16:30:55,688 DEBG received SIGCHLD indicating a child quit

 

From searching here and other places, I've so far tried:

 

- Switching from the nordlynx container to Gluetun for nordvpn wireguard as some comments said it could be VPN related.

- Removing a reference  to user0/download that I previously added in the container config in case that was messing with things

- Deleted perms.txt and let it rebuild.

 

Any help resolving this appreciated - I COULD just create a userscript to reboot the container nightly, but it seems wiser to solve it properly.

 

Hi,

 

I've actually had the same issue, recently got everything working with the nordlynx docker, added deluge port to nordlynx and was able to connect to deluge just fine. Now when I try, the page just doesn't load. I also get the same output in my deluge log.

 

I also notice in deluge row in docker, there are no ports, where there were before. Switching the docker back to the normal network fixes it and I'm able to connecto the UI just fine. I've been using deluge for a while now without the VPN and only very recently decided to buy a subscription to one, I've got in progress torrents that I don't want to lose by making the switch to DelugeVPN.

 

 

Any help/suggestions is appreciated!

 

Thanks, - Myles

[node]

On 8/8/2023 at 11:10 PM, Myleslewis said:

Hi,

 

I've actually had the same issue, recently got everything working with the nordlynx docker, added deluge port to nordlynx and was able to connect to deluge just fine. Now when I try, the page just doesn't load. I also get the same output in my deluge log.

 

I also notice in deluge row in docker, there are no ports, where there were before. Switching the docker back to the normal network fixes it and I'm able to connecto the UI just fine. I've been using deluge for a while now without the VPN and only very recently decided to buy a subscription to one, I've got in progress torrents that I don't want to lose by making the switch to DelugeVPN.

 

 

Any help/suggestions is appreciated!

 

Thanks, - Myles

 

I ended up going with delugevpn and no longer have the issue of the daemon going inaccessible - it's not too hard to setup any vpn for binhex-delugevpn and you can copy over your torrent states with a bit of Googling. It's been working perfectly and I like that it's a bit less complicated (therefore prone for something to go wrong) setup than using another container's network.

 

Honestly, I spent days on this, searching and trying different things, and ultimately the above was the right solution.

Edited September 3, 2023 by node

[Bushibot]

I have what I hope is a simple issue. I want to set the complete/incomplete and watch folder to something other than the default path /mnt/user/appdata/data.

I have different share to use like /mnt/user/datapool/watch etc

but deluge keeps telling the path doesn't exist (or any variation). Not sure what I'm missing or need to tweak for deluge to see the other share Outsite appdata?

Otherwise working great!

Thanks

[JonathanM]

12 minutes ago, Bushibot said:

I have different share to use like /mnt/user/datapool/watch etc

You will need to add a mapping with host side having the Unraid path, and the container side set to whatever folder you want to point deluge to. Docker containers can only access mapped paths, they have no way to get out of their own sandbox otherwise.

[Bushibot]

1 hour ago, Bushibot said:

I have what I hope is a simple issue. I want to set the complete/incomplete and watch folder to something other than the default path /mnt/user/appdata/data.

I have different share to use like /mnt/user/datapool/watch etc

but deluge keeps telling the path doesn't exist (or any variation). Not sure what I'm missing or need to tweak for deluge to see the other share Outsite appdata?

Otherwise working great!

Thanks

 

I reset and tried again with a new share 'download'. I set the deluge Container Path: /data/mnt/users/downlaod but I get the same no such path complaint from autoadd module for setting a watch folder, not such path... and torrents do not seem to be creating data in download complete/incomplete folders as set in deluge config. Mmm test torrent is not writing data to the directories. 

Edited September 4, 2023 by Bushibot

[JonathanM]

24 minutes ago, Bushibot said:

 

I reset and tired again with a new share 'download'. I set the deluge Container Path: /data/mnt/users/downlaod but I get the same no such path complaint from autoadd module for setting a watch folder, not such path... and torrents do not seem to be creating data in download complete/incomplete folders as set in deluge config.

https://forums.unraid.net/topic/57181-docker-faq/#comment-564306

 

[Bushibot]

2 hours ago, JonathanM said:

https://forums.unraid.net/topic/57181-docker-faq/#comment-564306

 

Wow that is kind of confusing but a little more digging on my end suggests this is actually PIA vpn issue. Maybe port forward?

The Logs show a couple warnings about can't detect external IP but eventual it says the VPN is up and starts the UI.

However from the CLI I can't ping DNS

sh-5.1# ping www.google.com
PING www.google.com (0.0.0.1) 56(84) bytes of data.
^C
--- www.google.com ping statistics ---
19 packets transmitted, 0 received, 100% packet loss, time 18450ms

 

but I can external and internal IP's.

sh-5.1# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=0.443 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=0.437 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=0.507 ms
^C
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2055ms
rtt min/avg/max/mdev = 0.437/0.462/0.507/0.031 ms
sh-5.1# 

sh-5.1# 
sh-5.1# ping 142.250.189.196
PING 142.250.189.196 (142.250.189.196) 56(84) bytes of data.
64 bytes from 142.250.189.196: icmp_seq=1 ttl=54 time=354 ms
64 bytes from 142.250.189.196: icmp_seq=2 ttl=54 time=353 ms
^C
--- 142.250.189.196 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 353.295/353.680/354.066/0.385 ms
sh-5.1# 

 

So it looks like DNS is broken but only this one container, all the containers work fine. Argh!

 

[binhex]

5 hours ago, Bushibot said:

Wow that is kind of confusing but a little more digging on my end suggests this is actually PIA vpn issue. Maybe port forward?

downloading to specific paths on your host has nothing whatsoever to do with the vpn provider or port forwarding, you simply do not yet grasp how docker bind mounts work.

 

firstly you need to create a new 'path' for the container or edit the existing path, e.g.:-

once this is done then wait for deluge web ui to be accessible and then configure deluge, for example assuming a host path of ' /mnt/user/datapool/watch' you would configure deluge watch to be '/data/watch' that is because ' /mnt/user/datapool' = '/data' thus the subfolder watch = '/data' + '/watch' you get it?.

[SoleInvictus]

I have a weird one. I use binhex-privoxyvpn to connect to my commercial VPN, PIA, then I route a few containers through that container so they're also using that VPN. This includes binhex-deluge. I do this by setting the network to none, then using "--net=container:binhex-privoxyvpn" in extra parameters for each container. Easy enough.

 

I've noticed that binhex-deluge is frequently exposed, connecting to my home network and showing my home IP. From what I understood, the connection was supposed be killed if this were to happen, yet it keeps happening without any interruption - binhex-deluge just kept chugging along, oblivious to being on the absolute wrong network.

 

This doesn't happen for the other containers. For example, I have a Firefox container set up similarly. While binhex-deluge is showing my home IP, Firefox shows my VPN's IP. They are set up identically, beyond having different port numbers.

 

Any idea what's going on? I'm not sure where to even start, so please let me know which config info, if any, to post. 

 

Thank you!

 

Edit: if this is a stupid way to configure this, I'm open to ideas. Just don't want to leak my IP.

Edited September 4, 2023 by SoleInvictus
I might be dumb.

[binhex]

29 minutes ago, SoleInvictus said:

While binhex-deluge is showing my home IP

can you detail exactly how you are identifying that deluge is using your isp assigned ip?, also please can you post your privoxyvpn log found at '/config/supervisord.log'

[SoleInvictus]

36 minutes ago, binhex said:

can you detail exactly how you are identifying that deluge is using your isp assigned ip?

Of course. Two ways: the IP address shown in the webGUI, plus I got a nasty email from my ISP regarding certain alleged activities, which is what made me realize all this was going on. What's extra weird is the IP in the GUI shows my ISP assigned IP, but curl ifconfig.io shows my VPN IP. I'm super confused here. 

 

Here's a recent copy of the log. Thank you so much for your help.

supervisord - Copy.log

 

Edit: something just occurred to me. Am I just starting up deluge too soon after system reboots? Is there a time period before privoxyvpn fully connects where that container allows access to the Internet without the VPN?

Edited September 4, 2023 by SoleInvictus
Ideas

[binhex]

24 minutes ago, SoleInvictus said:

Of course. Two ways: the IP address shown in the webGUI, plus I got a nasty email from my ISP regarding certain alleged activities, which is what made me realize all this was going on. What's extra weird is the IP in the GUI shows my ISP assigned IP, but curl ifconfig.io shows my VPN IP. I'm super confused here. 

 

Here's a super recent copy of the log. Thank you so much for your help.

supervisord - Copy.log 13.52 kB · 1 download

OK i have been able to replicate your issue partially - deluge web ui is showing the vpn ip address for me not my isp assigned ip but i can make deluge leak when incorrectly configured, which is what you have done, let me explain the issue...

 

So from your logs i spotted that you have set the following:-

VPN_INPUT_PORTS defined as '3000,3389,58846,58946,8112'
VPN_OUTPUT_PORTS defined as '3000,3389,58846,58946,8112'

This is incorrectly set, you only need to add in the web ui port, you have in effect permitted the deluge daemon incoming port to be accessible from your internet connection and thus its bypassing the vpn, the values should instead be as follows:-

VPN_INPUT_PORTS defined as '3000,3389,8112'
VPN_OUTPUT_PORTS defined as '3000,3389'

Note the fact that i have removed the default incoming ports (58846 tcp and 58946 udp), also you do not need an outgoing port defining for the web ui (port 8112).

 

This should fix your issue, to confirm go here:-  https://www.top10vpn.com/tools/do-i-leak/ and do a torrent ip leak test, do not worry about ipv6 its blocked, also ignore any web browser leaks, its of no concern as your browser will return your isp ip, its the torrent client you need to concentrate on.

[binhex]

1 hour ago, SoleInvictus said:

if this is a stupid way to configure this, I'm open to ideas. Just don't want to leak my IP.

oh and btw if i were you i would keep this simple and use the delugevpn image instead of doing network pass through, its a lot less hassle.

[SoleInvictus]

Oh man, I see it now! You're absolutely right - I'll just use DelugeVPN. I was doing it this way because one site I use requires one's Torrent client to connect using the same IP as one's browser; however, I can just pass DelugeVPN's network to a Firefox container and achieve the same effect. 

[Bushibot]

9 hours ago, binhex said:

downloading to specific paths on your host has nothing whatsoever to do with the vpn provider or port forwarding, you simply do not yet grasp how docker bind mounts work.

 

firstly you need to create a new 'path' for the container or edit the existing path, e.g.:-

once this is done then wait for deluge web ui to be accessible and then configure deluge, for example assuming a host path of ' /mnt/user/datapool/watch' you would configure deluge watch to be '/data/watch' that is because ' /mnt/user/datapool' = '/data' thus the subfolder watch = '/data' + '/watch' you get it?.

Yes. I did that, paths are sorted. however torrents just sit in deluge moving no traffic.

I got QB working, but only with wireguard, it has the save issue with open vpn.

but I guess I’m good now, QB is good enough.

Edited September 4, 2023 by Bushibot

[Mr. Savage]

On 6/17/2023 at 12:51 AM, Chriexpe said:

For some odd reason Deluge isn't saving any config, if I restart the docker/server it rolls back to default (any setting, for ex: Queue and Bandwidth).

I was about to post the same issue, but I figured it out while typing this. Turn off adblock, turn down Brave shields if you are using brave and disable anything that can block the settings from loading/saving.

If that doesn't work, use a different browser.

[mhertz]

@binhex Trying one last time gain your attention... Dumb-init don't work right in your image for gracefull shutdown of deluged, so I suggest either readd shutdown.sh back, or use my fix I post here, which includes a few extras: https://1drv.ms/u/s!Ajl1yq0BfB-dgt8n83N3_TYslpCPWg?e=LuWQKd

 

Some are strange admittedly, so i'm sure you can do better yourself in other ways, but just what I found works in extensive testing.

 

Thanks.

 

Context:

 

 

 

 

[ambipro]

Since I'm the provokation for @mhertz posting this reminder, and as I was going to reach out here myself, I'd like to point out what the request to address this revert/change provides for the user based on my experience using your container and conversations I've had with @mhertz

 

1. A significant portion of the restarting of the container with the ungraceful shutdown can lead to settings being removed, particularly loaded plugins. These will thus not return upon restarting the container.
2. The addition of -v on the info command makes it functional.
3. Graceful shutdown prevents most errors that would otherwise occur with active/seeding torrents, and can also make sure your stats are sent to the tracker before Deluge is exited.
4. Everything else mentioned in his previous posts/code he linked to...

 

The main way to prevent most of these issues currently, that I have found and use, is to simply 'Quit & Shutdown' before restarting or stopping the container. I typically do this and wait about 20 seconds to be safe.

 

This is not ideal, but is workable in most situations.

 

Hoping some form of what has been suggested/mentioned gets added/fixed in both libtorrentv1 and v2 tags.

 

Appreciate your containers and the effort put in, they've otherwise been phenomonal

 

Edit: Also - off topic, but there is a newer version of libtorrent for v1

Edited November 12, 2023 by ambipro

[binhex]

1 hour ago, ambipro said:

The addition of -v on the info command makes it functional.

Thanks to you both @mhertz @ambipro -  included the -v flag for info in the image, this will get included in the next image build.

 

In the meantime i shall take a look at dumb-init again and see what is going on, quite disappointed its not working as intended, process management and zombie reaping are a PITA in docker :-(.

[ambipro]

7 minutes ago, binhex said:

Thanks to you both @mhertz @ambipro -  included the -v flag for info in the image, this will get included in the next image build.

 

In the meantime i shall take a look at dumb-init again and see what is going on, quite disappointed its not working as intended, process management and zombie reaping are a PITA in docker :-(.

You and me both, fortunately there are a few options available if dumb-init can't be worked.