26 minutes ago, trevormiller6 said:

I have been using this with sonarr for years and never had an issue. Sonarr loads the torrents in just fine. They just don't download anymore.

 

Ok so I removed the docker with the image. Deleted the deluge folder in appdata that had the configs. Re-downloaded the docker and set it back up and now it works... Not sure why that fixed it but it did.

1 hour ago, trevormiller6 said:

 

Ok so I removed the docker with the image. Deleted the deluge folder in appdata that had the configs. Re-downloaded the docker and set it back up and now it works... Not sure why that fixed it but it did.

 

I did the same thing. Couldn't get it going for a while, then just gave up. Did setup qbittorrentvpn and got that going. After deleting the docker image plus the appdata folder, and then finally configuring it properly (didn't have the path's right) it's now working again. Got it going with Sonarr too (now just gotta figure out how to delete Torrents from Sonarr automatically).

On 12/31/2020 at 8:57 PM, binhex said:

firstly happy new year's eve guys!. 

 

ok so apt wont get ya far, as this docker image base is arch, and arch repo currently references deluge dev builds, thus the versions released, however i do understand your pain of having a dev build and i will consider a look into it to see if i can produce a one off non dev build for your guys on private index sites, obviously no progress on that tonight as im currently enjoying my beer donations, thanks everyone!.

Hey Binhex have you made any progress on a non dev deluge build? I could really do with being able to seed on my private tracker!

On 1/6/2021 at 1:59 AM, nfragol said:

If you use a public torrent, does it download properly ?

I just tried and yes a public torrent started a download.

 

13 hours ago, gergtreble said:

Hey Binhex have you made any progress on a non dev deluge build? I could really do with being able to seed on my private tracker!

hmm had a little look into this and it looks like the user agent is already impersonating the latest stable version, so as far as private trackers go they should be seeing version 2.0.3, here is the file hack used during the build of the package on arch repo:-

https://github.com/archlinux/svntogit-packages/blob/packages/deluge/trunk/user-agent-override.diff

 

are you positive that the private tracker is detecting a dev version? and you are using the 'latest' tag right?

Edited January 8, 20215 yr by binhex

33 minutes ago, binhex said:

hmm had a little look into this and it looks like the user agent is already impersonating the latest stable version, so as far as private trackers go they should be seeing version 2.0.3, here is the file hack used during the build of the package on arch repo:-

https://github.com/archlinux/svntogit-packages/blob/packages/deluge/trunk/user-agent-override.diff

 

are you positive that the private tracker is detecting a dev version? and you are using the 'latest' tag right?

Thanks Binhex! 

 

I was not implicitly calling the :latest flag in my docker config. I just set that and refreshed. No packages changed so I guess I was already on latest. I'm still not able to seed and looking at the message in the tracker (attached) it seems they are seeing it as a 2.0.3 release, so the user agent switch is working. But they are still somehow able to notice its a dev version. Looks like they are using the 'peerid' to determine this? 

32 minutes ago, gergtreble said:

Thanks Binhex! 

 

I was not implicitly calling the :latest flag in my docker config. I just set that and refreshed. No packages changed so I guess I was already on latest. I'm still not able to seed and looking at the message in the tracker (attached) it seems they are seeing it as a 2.0.3 release, so the user agent switch is working. But they are still somehow able to notice its a dev version. Looks like they are using the 'peerid' to determine this? 

thanks for the screenshot, it looks like its the peerid thats leaking the fact its a dev build, i have posted a bug on arch repo, lets see if they will fix it first, if not then i will have to roll my own package, link to the bug:- https://bugs.archlinux.org/task/69250

1 hour ago, gergtreble said:

Thanks Binhex! 

 

I was not implicitly calling the :latest flag in my docker config. I just set that and refreshed. No packages changed so I guess I was already on latest. I'm still not able to seed and looking at the message in the tracker (attached) it seems they are seeing it as a 2.0.3 release, so the user agent switch is working. But they are still somehow able to notice its a dev version. Looks like they are using the 'peerid' to determine this? 

ok i have had a further poke about and ive found the line that looks to set the peerid, can you try the following:-

 

1. left click deluge icon and select console

2. copy and paste the entire line below, this MUST be exactly as it is, press return to execute it.

sed -i -e "s~peer_id = lt\.generate_fingerprint('DE', \*version_list)~peer_id = \'--DE203s--\'~g" '/usr/lib/python3.8/site-packages/deluge/core/core.py'

3. restart the container (do not edit any settings as this will remove the hack).

4. attempt connection to private tracker, let me know how it goes, if it works i can include this in the image.

 

DISCLAIMER - this might be still detected and may incorrectly look like ratio cheating and thus you maybe banned, i am NOT responsible for this.

10 minutes ago, binhex said:

DISCLAIMER - this might be still detected and may incorrectly look like ratio cheating and thus you maybe banned, i am NOT responsible for this.

Well they have not banned me yet! But I'm still being flagged as a dev build by the peerID. Looks like the "-D" string is triggering it. (D for dev?)

41 minutes ago, gergtreble said:

Well they have not banned me yet! But I'm still being flagged as a dev build by the peerID. Looks like the "-D" string is triggering it. (D for dev?)

ok i think i see the issue, try this hack same procedure as above:-

sed -i -e "s~peer_id = substitute_chr(peer_id, 6, release_chr)~peer_id = \'--DE203s--\'~g" '/usr/lib/python3.8/site-packages/deluge/core/core.py'

 

1 hour ago, binhex said:

ok i think i see the issue, try this hack same procedure as above:-

sed -i -e "s~peer_id = substitute_chr(peer_id, 6, release_chr)~peer_id = \'--DE203s--\'~g" '/usr/lib/python3.8/site-packages/deluge/core/core.py'

 

Same issue still, seems they are grepping the first few characters of the peerID for the -D string and using it to indicate its a dev build?

 

Anyone know what the peerID for the latest non dev build is? (Or can help me find out how to find that?)

8 minutes ago, gergtreble said:

they are grepping the first few characters of the peerID for the -D string and using it to indicate its a dev build?

no i dont think thats it, the peerid --DE = deluge, 203 = version and s = stable, if the peerid was indicating a development build then the last character would be a D, as in peerid = --DE203D, which is basically what it was set to before you applied the hacks.

 

here is the explanation, taken straight from the source code:-

 

        This creates the peer_id and modifies the release char to identify
        pre-release and development version. Using ``D`` for dev, daily or
        nightly builds, ``a, b, r`` for pre-releases and ``s`` for
        stable releases.

        Examples:
            ``--<client><client><major><minor><micro><release>--``
            ``--DE200D--`` (development version of 2.0.0)
            ``--DE200s--`` (stable release of v2.0.0)
            ``--DE201b--`` (beta pre-release of v2.0.1)

        Args:
            version (str): The version string in PEP440 dotted notation.

        Returns:
            str: The formattted peer_id with Deluge prefix e.g. '--DE200s--'

        """

 

Edited January 8, 20215 yr by binhex

Ah gotcha! I'm all out of ideas then! They must be identifying the version in some other way.

 

 

Just now, gergtreble said:

Ah gotcha! I'm all out of ideas then! They must be identifying the version in some other way.

 

 

had another stare at the code, there is a release_chr which looks like it MIGHT be also in play, can you firstly edit your container, change a value then change it back and click apply, this then resets your container to remove the previous hacks, then try the hack below, ensure you copy the complete line, and do not remove any spaces:-

sed -i -e "s~peer_id = substitute_chr(peer_id, 6, release_chr)~peer_id = \'--DE203s--\'\n        release_chr = \'s\'~g" '/usr/lib/python3.8/site-packages/deluge/core/core.py'

if this doesnt work then i will have to throw in the towel for now.

7 minutes ago, binhex said:

had another stare at the code, there is a release_chr which looks like it MIGHT be also in play, can you firstly edit your container, change a value then change it back and click apply, this then resets your container to remove the previous hacks, then try the hack below, ensure you copy the complete line, and do not remove any spaces:-

sed -i -e "s~peer_id = substitute_chr(peer_id, 6, release_chr)~peer_id = \'--DE203s--\'\n        release_chr = \'s\'~g" '/usr/lib/python3.8/site-packages/deluge/core/core.py'

if this doesnt work then i will have to throw in the towel for now.

Sadly we still have the same behaviour. I'd love to know how they are determining that its not an allowed client. Maybe the Deluge and Libtorrent versions don't match or they expect different version? 

 

 

Either way appreciate the effort here Binhex,  think you also improved my sed!

 

1 hour ago, gergtreble said:

'd love to know how they are determining that its not an allowed client.

me too!.

1 hour ago, binhex said:

me too!.

In the meantime I've spun up your rutorrentvpn docker and spent the afternoon migrating that specific trackers torrents on to that. So at least I'm seeding again. 

 

@binhex I might stop trying keep up with your Docker on my Docker DelugeVPN-flexget, getting too complicated for my programming skills.  I got it updated but I think because I am using Airvpn the forwarding on 443 is not working.  My cache pool on 5yr old SSDs got hooped and I had to buy new SSDs and start over.

 

https://github.com/paulpoco/arch-delugevpn/tree/dev

 

I see now you can assign one Docker to use another's Internet connection(at least I saw that in SpaceInvaders YouTube).  I.e. I'll update my Flexget only Docker and install it and assign it the DelugeVPN internet connection.  Will the Flexget be able to send the Deluge torrent to the DelugeVPN Docker. 

 

I installed your Docker and it works right away.  Maybe I need to take your current one and start over, my Flexget stuff was kind of easy to add.  Well another night then.

Ok like said I am running this Docker but I don't understand the port Forwarding?   I am with Airvpn, welll ar least until March.

1 hour ago, Paul_Ber said:

Ok like said I am running this Docker but I don't understand the port Forwarding?

what dont you understand about it?, its simply a port that is supplied by your vpn provider that you configure the app to use as the 'incoming port'

31 minutes ago, binhex said:

what dont you understand about it?, its simply a port that is supplied by your vpn provider that you configure the app to use as the 'incoming port'

When you generate the openvpn config at Airvpn it selects 443 but is that different than the forwarded port?  On Airvpn I already had the forwarded port setup from before. 

 

I put the port in Deluge.

 

Not downloading on a test Ubuntu torrent. 

 

 

This is from Airvpn forwarded ports page.

1 minute ago, Paul_Ber said:

When you generate the openvpn config at Airvpn it selects 443 but is that different than the forwarded port?

yes, port 443 will be the port used to connect to airvpn NOT the port forward.

18 minutes ago, binhex said:

yes, port 443 will be the port used to connect to airvpn NOT the port forward.

I see these 2 addresses in the logs.

I deleted the port forward at Airvpn and requested a new one, updated Deluge incoming port then the download started then speed went lower until it stopped. 

Edited January 11, 20215 yr by Paul_Ber
Add that I changed incoming port

Here is part of the logs:

2 minutes ago, Paul_Ber said:

Here is part of the logs:

i woldnt be too concerned with this, if you can see the web ui for deluge then the vpn is up and running, and yes ipv6 is blocked via iptables in any case to prevent ipv6 leakage.