12 minutes ago, nekromantik said:

i tried and same issue so updated original post to remove that line as it happens on both settings

 

If sonarr and radarr also are on a custom bridge network that's why. They all need to be on the normal bridge. All containers using a custom bridge network are isolated from the host. 

3 minutes ago, strike said:

If sonarr and radarr also are on a custom bridge network that's why. They all need to be on the normal bridge. All containers using a custom bridge network are isolated from the host. 

I tried and still same issue, Its not that.

To rule out the custom bridge I downloaded another Deluge container and set up in custom bridge and it worked. Sonarr and Raddar can connect.

So this issue is only on the binhex ones but I prefer binhex as he includes VPN built in.

this is not a issue with host this is container to container. I can access the UI fine. Bridge or custom bridge both. Its just contaner to container that does not work. All containers can connect to 8118 on this but not on 8112.

Edited September 29, 20205 yr by nekromantik

4 minutes ago, nekromantik said:

I tried and still same issue, Its not that.

To rule out the custom bridge I downloaded another Deluge container and set up in custom bridge and it worked. Sonarr and Raddar can connect.

So this issue is only on the binhex ones but I prefer binhex as he includes VPN built in.

I'm sure the other deluge container worked with custom bridge but that doesn't mean this container should too. There are strict iptables rules in place in this container to prevent leakage, which may block the connection. Post your docker run command for delugevpn and radarr and a screenshot of the deluge settings in radarr. Have you confirmed you have a working vpn tunnel? What error do you get trying to connect to deluge?

21 hours ago, strike said:

Yeah, this container doesn't support that.

Thanks Strike. All is working well now. I was using a different version of DelugeVPN that did support it previously, running the binhex one now and missed seeing that it needed to be in bridge. All good though! It's been awhile since I've had to troubleshoot anything, so it was good for me

11 minutes ago, strike said:

I'm sure the other deluge container worked with custom bridge but that doesn't mean this container should too. There are strict iptables rules in place in this container to prevent leakage, which may block the connection. Post your docker run command for delugevpn and radarr and a screenshot of the deluge settings in radarr. Have you confirmed you have a working vpn tunnel? What error do you get trying to connect to deluge?

Not sure why iptables would block the webUI port as thats not the port thats used for downloading torrents.

Yes the VPN is running fine.

I did not use docker run as I just used unRaid templates. attached the images

Error is it just times out when connecting to Deluge

Edited September 29, 20205 yr by nekromantik

14 minutes ago, nekromantik said:

Not sure why iptables would block the webUI port as thats not the port thats used for downloading torrents.

Yes the VPN is running fine.

I did not use docker run as I just used unRaid templates. attached the images

Well, you are still on a custom bridge network, which I told you isn't supported by this container. Change to normal bridge on all the containers which need to talk to each other. Then change the IP in radarr/sonarr. You also have issues with your volume mappings which doesn't match so you'll also need to correct that for the containers to work together. I'm referring to your downloads mapping. 

Edited September 29, 20205 yr by strike

13 minutes ago, nekromantik said:

Not sure why iptables would block the webUI port as thats not the port thats used for downloading torrents.

Yes the VPN is running fine.

I did not use docker run as I just used unRaid templates. attached the images

Error is it just times out when connecting to Deluge

Hey Nekromantik, this was exactly the issue I had when I switched the the binhex DelugeVPN docker to solve the PIA issue. You need to have it and Radarr/Sonarr all in bridge mode, not using their own IPs. Once I made that change everything was off to the races again.

ok i will see about normal bridge mode thanks both

18 hours ago, j2los said:

One of my trackers has blocked port 6890. I can't seem to override the default port. Is that hardcoded into this app? I see when I launch the container I get a 'watchdog-script' output saying it sets the port to 6890. 

Not sure if my question got lost or it's just stupid. Where can I alter this 'watchdog-script'? 

9 hours ago, Krisztian said:

@Nimrad! Use this file. Put it in the config/plugings folder. If restart doesn't help, go to preference -> plugins -> install. Choose the file from the folder.

I too am using it. It should work...

 

KK

Gee, thanks so much. I had an older version (0.6.1), this one worked. 

With the NextGen PIA network - do we want to go back to enabling strict port forwarding?

 

2 minutes ago, Geekd4d said:

With the NextGen PIA network - do we want to go back to enabling strict port forwarding?

 

yes indeed, if you dont do this then you wont get a working incoming port, make sure you do switch over to next-gen by following Q19:-

https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Edited September 30, 20205 yr by binhex

Just now, binhex said:

yes indeed, if you dont do this then you wont get a working incoming port.

Appreciate it! (Maybe add that to your pia post there so you don't get this same question a lot lol)

 

Seriously. thank you for the work you do on this and other containers

 

Because its been asked a few times - Yes i am working on WireGuard support now for PIA, its going ok but there is a fair bit to integrate it with the existing code so it may take a little while to code, but hopefully should be done fairly 'soon' (trademark limtech 🙂).

 

WireGuard users using other VPN providers (non PIA) - Question for you, is your wireguard config file static, or is there any dynamically generated parts to it?, please detail what is dynamic (if anything) and your VPN provider name please, im trying to make any code i do VPN provider agnostic as much as possible.

I am still unable to get deluge to connect using pia and the nex-gen openvpn files. Is there another change I have to make?  I thought it was delete the old gen files and replace with the nex-gen cert files amd open vpn location file.

Just popping in to salute you @binhex - great work at implementing fallback servers, and nextgen PIA ! 
Keep up the great work, it is very much appreciated

5 minutes ago, whitewraith said:

I am still unable to get deluge to connect using pia and the nex-gen openvpn files. Is there another change I have to make?  I thought it was delete the old gen files and replace with the nex-gen cert files amd open vpn location file.

did you update your docker image?

4 minutes ago, qbone said:

did you update your docker image?

I did to 2.0.4dev38 and it wasnt working, but then BAM!!! Now it works so not sure why it was being so stubborn.

 

I would like to say thanks to @Binhex. I appreciate your hard work and endless hours making sure idiots like me can use the dockers without issue.

PIA announces that the legacy servers will shut down at the end of October

 

Now that the next gen server support is in the latest, I guess it's time for me to update

1 hour ago, dukiethecorgi said:

PIA announces that the legacy servers will shut down at the end of October

 

Now that the next gen server support is in the latest, I guess it's time for me to update

I tried updating but Deluge v2 seems to be really buggy. Trackers just stop updating. Guess I'll see if PIA will issue refunds.

9 minutes ago, wgstarks said:

Guess I'll see if PIA will issue refunds.

I get it, but before you go through that hassle, maybe try one of the other binhex vpn enabled torrent clients to see if you can salvage the situation. The beauty of containers is that you can set up multiple versions to test without tearing down what you already have. I guess it boils down to how you want to spend your time.

1 hour ago, dukiethecorgi said:

PIA announces that the legacy servers will shut down at the end of October

 

Now that the next gen server support is in the latest, I guess it's time for me to update

I get they are moving over to next gen but all their update on their helpdesk site stated they were having problems with port forwarding on legacy servers and where "working to fix the issue". I think its now fair to say they had no intention to fix the issue. PIA is always trying to claim transparency but a move like this really doesn't give me any confidence. I'm sure port forwarding matters to a very small percentage of their customer base but its still a feature of their service that should work.

Edited October 1, 20205 yr by TrueImpulse

I wonder if earlier versions of delugevpn will work with nextgen servers if port forwarding is disabled? I’m not using port forwarding right now anyway.

Edited October 1, 20205 yr by wgstarks

1 hour ago, jonathanm said:

I get it, but before you go through that hassle, maybe try one of the other binhex vpn enabled torrent clients to see if you can salvage the situation. The beauty of containers is that you can set up multiple versions to test without tearing down what you already have. I guess it boils down to how you want to spend your time.

Good advice. Might give rtorrent a shot.

Hello, im downloading to my download share on the cache folder and even after using the mover cache isnt emptying.
My torrents are still seeding from cache maybe this is why ?

Is it possible to seed from array and if yes, is there no problem while doing it ?

Edited October 1, 20205 yr by Kishin