[Plugin] Auto Remove Plus v2.0.0

Suggest, post, or discuss plugins for Deluge
basher
Member
Member
Posts: 14
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.
basher
Member
Member
Posts: 14
Joined: Wed Sep 29, 2021 8:42 am
Location: Estonia

Re: [Plugin] Auto Remove Plus v2.0.0

Post by basher »

@mhertz, any idea what's the proper way of accessing finished status in Deluge 2?
Torrents still have is_finished attribute on them, but it's unclear whether it's kept as up-to-date as querying via

Code: Select all

torrent.get_status(['is_finished'], update=True)['is_finished']
mhertz
Moderator
Moderator
Posts: 1329
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: [Plugin] Auto Remove Plus v2.0.0

Post by mhertz »

To me looks like they should be comparable, when looking through deluge/core/torrent.py.

As said, I'm not very good at this, but looks like the deluge2 introduced 'update' flag of get_status() which updates 'self.status' isnt even used here regardless, as is_finished through get_status() gets queried from self.is_finished from _create_status_funcs(), which translates to self.state.is_finished. Honestly I'm getting confused looking through it all and keep blanking out upon what is what after little time lol, regarding deluge and it's libtorrent interactions, but I think both is fine, and as said, even without the 'update' flag in get_status() then is_finished goes through another route anyway I think, so not using old values which would make sense also for something like is_finished, but again take with grain of salt, and I apologize in advance if saying something ludacris.

I don't know which most propper neither - personally I always used the get_status one(the few times I've done such, that is), but just because first one I learned, or somewhat learned more appropriately formulated :)

Anyway, good question :)
Post Reply