Re: [Plugin] Auto Remove Plus v2.0.0
Posted: Sat Oct 16, 2021 9:16 am
Has someone else having problems meeting their tracker's minimum seed time requirement using this plugin?
Don't think issue is with the plugin itself, but either with trackers disagreeing with Deluge on the actual seeding time, or how Deluge defines the seed_time property.
Note this tracker starts counting seeding time from the moment torrent has been downloaded.
Querying docker-console for info also suggests that deluge does differentiate between seeding time & active time:
-------------------------------------
My tracker requires minimum 7days of seed time. ARP.conf has following rule:
Yet tracker lists following torrents as hit-and-runs:
From the logs I gather the first item in that list was added to Deluge at 2021-10-08 18:45:16, and removed by plugin at 2021-10-15 20:15:27. This suggests the 169hour config is honored properly. Can't confirm whether the torrent was originally downloaded fast enough to fit into the hour buffer, but as shown above, deluge already appears to start counting seeding time after download has completed, so configuring the rule at exactly 168h (=7days) should work as well.
What's the rub here? How to deal with it?
Edit: I think it might have to do with tracker announce lagging behind, and torrents getting deleted before next tracker update, hence tracker is unaware of the latest seeding statistics. This could explain the torrents that are missing 5-20mins of seed time. What's up with the one that's missing 15hours is still a puzzle.
Reannouncing tracker just prior to removing torrent could be an option here. this thread offers some hints.
Edit2: it's not that, at least not only.
Having rules
A torrent removal was still triggered with following debug msg:
Edit3: the debug msg above was due to torrent stats being queried after it had been removed. Think calling libtorrent's force_reannounce() solves the premature torrent removal problem.
Don't think issue is with the plugin itself, but either with trackers disagreeing with Deluge on the actual seeding time, or how Deluge defines the seed_time property.
Note this tracker starts counting seeding time from the moment torrent has been downloaded.
Querying docker-console for info also suggests that deluge does differentiate between seeding time & active time:
Code: Select all
Seed time: 6 days 01:50:46 Active: 6 days 01:54:52
My tracker requires minimum 7days of seed time. ARP.conf has following rule:
Code: Select all
[
"or",
"func_seed_time",
169 <-- note this is 7days + 1hour for buffer
]
Code: Select all
Downloaded Uploaded Ratio Seeding Time
27.3 GB 11.68 GB 0.43 6 days, 23 hrs, 54 mins, 7 secs
35.91 GB 8.43 GB 0.23 6 days, 23 hrs, 57 mins, 18 secs
29.44 GB 10.7 GB 0.36 6 days, 8 hrs, 53 mins, 30 secs <--- some 15hours of seed time unaccounted for???
What's the rub here? How to deal with it?
Edit: I think it might have to do with tracker announce lagging behind, and torrents getting deleted before next tracker update, hence tracker is unaware of the latest seeding statistics. This could explain the torrents that are missing 5-20mins of seed time. What's up with the one that's missing 15hours is still a puzzle.
Reannouncing tracker just prior to removing torrent could be an option here. this thread offers some hints.
Edit2: it's not that, at least not only.
Having rules
Code: Select all
[
"or",
"func_ratio",
4
],
[
"or",
"func_seed_time",
169
]
Need to investigate further as to why the rule is triggering.seed_time: [593991], ratio: 3.84631248474 # that's 164.9975 hours of seed time
Edit3: the debug msg above was due to torrent stats being queried after it had been removed. Think calling libtorrent's force_reannounce() solves the premature torrent removal problem.