Deluge, Incoming Port and Autobrr

[phoenix1of1]

Hi all,
Just for clarity, I use;
Win 10
Private Internet Access VPN
A static IP address from the VPN
A dynamic forwarded port from the VPN
Deluge 2.1.1

I am attempting to connect autobrr to Deluge using the standalone client. I assumed that Deluge would run a local daemon but it doesn't appear to.
When using Deluge in standalone mode, I can freely set the incoming port to reflect the forwarded port from my VPN and I can establish inbound and outbound connections without issue with the exception that autobrr cannot connect to the standalone client.

So I've seen that Deluge is just a GUI unless you run it in thin client mode to start up a daemon locally. That is not a problem and to add to that, I can use autobrr with Deluge in thin client mode so that it pushes items to Deluged but, this is where it get's weird.

Why?

I cannot set the incoming port for port forwarding. For example, my VPN could assign me a port of 58753 and so I enter that in to the settings box, hit apply and then, instead of setting Deluged to use that port, it adds one so that it is 58754 which then means I can only make outbound connections and accept no inbound connections as Deluged is using the wrong port.

Can anyone here shed some light on the situation because it is driving me nuts.

The daemon port is fine because as I said above, in thin client mode with a running daemon, I can use Deluge and Autobrr as intended but only to grab stuff. I then have to revert back to the standalone client if I wish to have an open port for inbound connections.

Can someone do me a solid and either explain what I am not doing or have missed and if needs be, beat me senseless with a wet fish!

Cheers in advance!

[phoenix1of1]

Turns out that that Nat-PMP was the culprit. Disabling this in the client stops Deluge from assigning the wrong port.

[mhertz]

Thanks for posting your solution, though however imho sounds like a coincidence, as should in no way behave like that under usual circumstances, and neither do here in quick general testing. If such issue should exist, then would be related to a specific libtorrent version bug, but as said sounds unlikely imho, though of-course could be wrong and likewise would need a proper wet fish beatdown in return(as you said, lol btw )