Max. Torrents setting is misleading when used with Min. HDD Space criteria

[dgw]

My current plugin settings are as follows:

I recently changed the Seed Time condition from 7 to 15, but the issue is the same.

Torrents are removed in a somewhat unpredictable order. I expected that, since the primary condition is to remove by seed time, the torrents that have been seeding the longest would be removed first, with torrents of the same age in days being removed in order of highest to lowest ratio. But it seems the plugin is sorting in some other order, so more recently added torrents get removed first—sometimes torrents that just barely meet the minimum seed time.

It would make more intuitive sense to sort torrents according to the removal criteria, and process them in order such that the torrents that "most meet" the criteria (higher seed time, higher ratio, more seeders, less recent Date Added) are removed, leaving the newer torrents to continue accumulating seed time/ratio/etc.

[omaralvarez]

Here is the thing, when you guys have 0 in the Max. Torrents field, the removal order does not matter. Just think about it, if you want 0 torrents seeding, as soon as torrents meet the removal criteria, they will be deleted, the order does not matter.

If on the contrary you would have say 100 in that field. Then the order does matter, the torrents will be ordered by removal criteria, in your case Seed Time and Ratio and then only the excess torrents that have the highest Ratio or Seed Time will be deleted.

I have tested the sorting algorithm extensively and it is working properly, and what you say makes sense. The minimum criteria is there for that reason, if you want more seed time, just raise the minimum criteria. If you want for torrents to exceed that criteria and not get deleted, use a higher amount of torrents in the Max. Torrents field.

[dgw]

The plugin is not removing all torrents that meet the removal criteria, though. It is only removing enough to get the free disk space above the configured minimum.

When I had the seeding maximum set to -1, no torrents were ever removed, even when free disk space was well below the configured minimum. I seem to recall having some other issue with a seeding maximum >0 but don't recall what it was specifically.

At any rate, I don't want to constrain the number of torrents; I want to remove seeding jobs ONLY if free disk space falls below the minimum value.

Maybe I've misdiagnosed why my settings don't work as expected, and I haven't actually found a bug as I thought. But I'll keep trying tweaks, and if you have any further tips other users with my use case may also find them useful.

Thanks!

[dgw]

With Max. Torrents set to 16, and 5.5 GiB of disk space left, the plugin has stopped removing with 21 torrents seeding.

I will update the title of this issue to better describe the difference between perception (Max. Torrents is a hard maximum, that will cause removals even if not required to maintain minimum free disk space) and reality (Max. Torrents can be 1, and torrents will still only be removed up to disk space threshold if threshold != -1).

[dgw]

Returning to the original issue, I just watched the plugin remove a torrent to free up disk space after applying a temporary change to the disk threshold. Using the settings below, a torrent added on July 9 was removed instead of the oldest torrent in the list, added July 7.

Knowing that the torrents added on this particular server almost never take more than an hour to download at most, it seems there might be a bug in the sorting after all. For the moment I am out of torrents that are old enough to be removed for testing, but I will conduct additional tests when I can.

[omaralvarez]

Ok, whenever I have time, I will double check this, I think I may know why this is happening.

[omaralvarez]

Just to clarify what was going on. The problem was that before the plugin did not account for disk space. So the order of deletion of torrents did not matter. The plugin just calculated which ones had to be deleted (the ones that had the highest ratio, etc.) and deleted them all.

Now order does matter, and we needed to delete them in the opposite way that they were being deleted (the sort was correct). Still, with this, one needs to be careful, since Deluge provides an async API, and disk space may not be freed at the same speed that the loop executes.