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.