Deluge Forum

I recently updated my distro from jessie to bullseye and reinstalled deluged and deluge-web.
Since then, deluge no longer remove the torrents upon reaching a share ratio of 2.
Before the update, with this exact configuration, deluge correctly removed torrents when reaching the share ratio. Am I missing something?

deluged 2.0.3
deluge-web 2.0.3
libtorrent: 1.2.9.0
Python: 3.9.2
OS: Linux Raspbian GNU/Linux 11 bullseye

I also tried to manually remove the torrents with share ratio >= 2, uncheck and check again the remove at share ratio option.
The issue persist: newly added torrents have reached the target share ratio but were not removed.

Hi,

Do you maybe have a plugin installed or something. A plugin as far as i have come to understand take priority over the general settings of Deluge. So even IF you have configured it differently, the plugin settings are being used.

No extra plugin installed, only the default plugins, which are disabled anyway.

I cannot reproduce this i'm affraid, and sorry ment write before(did ran some tests at your first postage etc), but got sidetracked honestly, and then forgot, thanks shinger for reminding us I just re-tested deluge 2.0.3 in a venv with libtorrent 2.0.9 in my used distro, but did work fine here. I would try fresh deluge profile and otherwise enable debug-logging and check if any notes of issues/errors, though with that old deluge and newer libtorrent, then you will have a bunch of errors regardless, and I don't believe that debian package is patched for most of these issues still, atleast last I checked, but regardless, and as said, clean profile i'd highly suggest, atleast temporarilly for quick testing, e.g. rename deluge-profile to end in "-bak"(or just start new instance with 'deluged -c deluge-test') and then set share-ratio in web-UI or core.conf to 0.01(though gtk-UI reverts to min 0.5 whenever opening it's preferences dialog, so need change core.conf again afterwards), and as you inferred, have to add torrents after changing these settings, as they don't apply to current items.

Good luck.

I've conducted some more tests. My bad, the "remove torrent when share ratio reached" feature works, more or less.
The issue here, if we can call it so, is that the removal happens "late". Let me explain.

Let's say I added a bunch of torrents yesterday (through deluge-web), and closed the web page after that. During the night, all the torrents reached the target share ratio. Today I open deluge-web.

How it worked (as far as I know) in the past:
The torrents were immediately removed when they reached the target share ratio, during the night. Today deluge-web shows me an empty list of torrents - as expected.

How It works now:
The torrents were not immediately removed when they reached the target share ratio during the night. Today deluge-web shows me all the torrents, with a share ratio way bigger than 2. However it's almost like the opening of deluge-web triggered a check of the share ratios. After a while (seconds, sometimes minutes) all the torrents are removed, one by one.

avalloneandrea wrote: ↑Thu Feb 22, 2024 2:24 pm [...] However it's almost like the opening of deluge-web triggered a check of the share ratios. After a while (seconds, sometimes minutes) all the torrents are removed, one by one.

Sorry, I completelly forgot this indeed being an issue, and later gracefully fixed by the good gazpachoking, and included in deluge v2.10+.

Here's a command-line for deluge 2.0.3 users if wanted. Note if instead applying patch manually from above linked commit, then need make several code/patch changes firstly, as else will fail apply since the commit is made after deluge 2.0.5 released, so not compatible with deluge 2.0.3, and which I fixed in my automated command-line. Edit: Actually I see all the sed/grep work was needless in this case here, as the '-F3' arg I added for workarounding last change, actually was enough for everything, as all incompatibilities where in context parts only, but meh, I left as doesn't hurt - learnt something new atleast

Edit2: Revised line, just for heck of it, small as possible so dismiss the missing file notion in success message, as just forced it('-f') here: (If ran previous line, then fine, no diff whatsoever, well that's not fully true, as one chunk applied it's imports above instead under, but in effect there's no diff atleast I just meant.)

It worked, thank you!

Be happy if your torrents don't upload beyond the ratio limit, because in a little percentage mine do... so I obliged myself to limit the upload bandwith to limit that overcoming.