[Plugin] Auto Remove Plus v2.0.0

Suggest, post, or discuss plugins for Deluge
basher
Member
Member
Posts: 11
Joined: Wed Sep 29, 2021 8:42 am
Location: Estonia

Re: [Plugin] Auto Remove Plus v2.0.0

Post by basher »

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:

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
  ]
Yet tracker lists following torrents as hit-and-runs:

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???
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

Code: Select all

      [
        "or", 
        "func_ratio", 
        4
      ], 
      [
        "or", 
        "func_seed_time", 
        169
      ]
A torrent removal was still triggered with following debug msg:
seed_time: [593991], ratio: 3.84631248474 # that's 164.9975 hours of seed time
Need to investigate further as to why the rule is triggering.
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.
Post Reply