[FEATURE REQUEST] Change Port before start, with config file

[olvier]

Hi again ;)

TL;DR Do you see a chance, to change the port in the qbit-config-file, before the container starts? :)

In my own and old bash-script,

i double checked and changed the ports via API and also via config-file. So, when qbit starts, the port is already the right one.

Now, it first starts with the old (and now wrong) port, and then change it. At the tracker, the old (and now wrong) port is recorded at the beginning. Afterwards the tracker gets the new port, but is un-connectable for some time.

Do you see a chance, to change the port in the qbit-config-file, before the container starts? :)

Extract from my old own bash-script

sed -i "s/PortRangeMin.*/PortRangeMin=${X}/"  /volume1/docker/qbittorrent/movies_config/qBittorrent/qBittorrent.conf
sed -i "s/PortRangeMin.*/PortRangeMin=${Y}/"  /volume1/docker/qbittorrent/series_config/qBittorrent/qBittorrent.conf

[t-anc]

Hi again :) I really prefer the API way, specially since I introduced a standalone mode not running in the same container than qbittorrent. I remember thinking about adding an auto 'reannounce' after a port change, but I my memories Qbittorrent already re-announce to trackers after a port change. However I can't find where I saw that so maybe I'm wrong. In that case I can implement an API call after a port change to reannounce all torrents. Anyway, I'm not too keen about changing config files directly, I can't be sure the mod will run before qbt, and it needs quite a bit of changes in the code to implement this. I don't need this but I can leave this issue open and if enough people are interested I can take a look.

Do you know anything about qbt reannouncing after a port change ? Does an auto reannounce fit your need ? Thank you

[olvier]

Hi :)

I've tested re-announcing in qbit by hand, but it didnt changed anything. So i start with bad/wrong port and have to wait, that the tracker recognize the new and correct one. I edited my own script, that it edits the port in the conf, every minute. Maybe i could add some wait into the compose, to be sure that qbit starts with the correct port.

[olvier]

[i did not open a new topic, because problem is nearly the same]

hi again :)

I have some problems with those linux image trackers. they would recognize an IP-change quite fast, but not a change of a port. so for hours i am "not connectable".

i would see a chance, when the active torrents are paused before changing any ports, wait some seconds, change ports and re-activate those torrents again. So they are cleanly disconnected from tracker (hopefully).

Do you see any chance?

[t-anc]

Hi ! First of all, I'm a bit of a newbie for most of torrenting concepts, so excuse me if I don't understand some basic stuff ^^

If I understand correctly your issue, some trackers don't aknowledge the port change fast enough, but if you pause the torrent, change the port, and start the torrent again, it would works faster ? You'd like the mod to do that ? Wouldn't a reannounce do the same ? As I said before, I could implement a trigger to make the api call to reannouce all torrent after a port change, but I think qbt already does that as default behaviour. As for pausing torrents before a change and re-start them after, that seems troublesome to implement, and overkill to do.

As for the config file change that's just my point of view, if someone want to fork this repo to implement this, feel free. And if many people are interested or if someone wants to make a PR, I can take a look but I'm not to keen on it.

It's possible I completly missed your point, if so don't hesitate to correct me !

[olvier]

If I understand correctly your issue, some trackers don't aknowledge the port change fast enough, but if you pause the torrent, change the port, and start the torrent again, it would works faster ?

Yes! Hours vs "seconds". Because its stopped cleanly and started afterswards with new port. If you have 100s of seeds, the tracker aren't amused, when you/the linux images aren't available and you are the last seeder ;)

Wouldn't a reannounce do the same ?

Unfortunately not.

It's possible I completly missed your point, if so don't hesitate to correct me !

You did not, i kinda mixed two topics with two ideas of optimization ;)

[github-actions[bot]]

This issue has been open for 30 days with no activity. Marked as stale.

[github-actions[bot]]

This issue has been inactive for 14 days since being marked as stale. Closing.