Opened 6 years ago

Last modified 7 months ago

#2059 assigned feature-request

[lt.sess_set.tracker_backoff] Add support for libtorrent tracker_backoff option

Reported by: AlderaaN Owned by:
Priority: major Milestone: 2.x
Component: Core Version: 1.3.6
Keywords: tracker, update, aggressive, timeout, time-out Cc: pcfregister@…

Description

Greetings.

I use autodl-irssi to match the latest releases in my tracker.

Here's what happens:

  1. My autodl is set to pass on .torrent files after 35 seconds to Deluge's watch-dir.
  1. Deluge picks up the .torrent.
  1. Deluge tries to update for the tracker once.
  1. If the uploader of said torrent didn't perform "update tracker" on his client in a timely manner - Deluge will time-out and set itself to retry once more in no less than 30 minutes!
  1. Those first 30 minutes, in SeedBox?-heavy private trackers, could mean you either:
  1. A. Scored big: if Deluge managed to sync up with the tracker and you caught the swarm early.
  1. B. Failed miserably: if Deluge timed-out for 30 minutes on the first announcement, and you managed to destroy your ratio on a particular torrent.

This is something that doesn't happen in rTorrent/ruTorrent - where it seems to keep on auto-retrying in very small intervals until it's able to sync up with the tracker.

And so, I kindly ask you implement a more aggressive initial tracker-updating mechanism, just until Deluge is able to pick up and sync with the tracker.

Something in the range of every 5 seconds would be very good. Again, just until it syncs up with the tracker.

BTW: increasing the upload-delay-secs = to anything higher than 35 seconds i quite futile, since there could always be those odd torrents where even after 90 seconds they'd still won't sync, and after 150-180 seconds they would..

Specs: Deluge Client: v1.3.4 Deluge Server: v1.3.4 libtorrent: v0.15.10.0 OS: Linux version 2.6.39.2-grsec-xxx-r1.5.1 (root@…) (gcc version 4.4.3 (Gentoo 4.4.3-r2 p1.2) ) #1 SMP Wed Jun 29 00:47:56

EDT 2011

Change History (13)

comment:1 Changed 6 years ago by Cas

  • Component changed from other to libtorrent
  • Milestone 1.3.x deleted
  • Version 1.3.4 deleted

This is an issue that you would need to discuss with libtorrent developer.

comment:2 Changed 6 years ago by AlderaaN

Isn't this up to Deluge's Client/Server? to perform those updates?

comment:3 Changed 6 years ago by AlderaaN

OK,

Following Cas's recommendation to run this by the developer of libtorrent - I've done so, he has accepted the request and marked it some 30 hours ago as 'fixed': http://code.google.com/p/libtorrent/issues/detail?id=301

If you could please coordinate efforts and have it implemented in the next release - that would be appreciated!

This fix actually negates the need to "babysit" Deluge each time a new torrent is being passed to it from a Tracker that allows some of its torrents releases to be listed just before the the main seeder is actually present in the swarm.

Regards,

comment:4 Changed 6 years ago by Cas

  • Component changed from libtorrent to core
  • Milestone set to 1.4.0

This change has been added to libtorrent trunk so this will not be in the Deluge 1.3 however it can be added to the development branch.

From the libtorrent docs:

tracker_backoff determines how aggressively to back off from retrying failing trackers. This value determines x in the following formula, determining the number of seconds to wait until the next retry:

delay = 5 + 5 * x / 100 * fails2

It defaults to 250.

This setting may be useful to make libtorrent more or less aggressive in hitting trackers.

Python binding for tracker_backoff is in session_settings.

comment:5 Changed 6 years ago by Cas

  • Summary changed from Deluge not agressive enough during initial (first) tracker update routine to Add support for libtorrent tracker_backoff option

comment:6 Changed 6 years ago by AlderaaN

Thanks Cas!

Would you consider compiling this with a lower value, which would result in an *initial* Tracker "back-off" timeout of 1 minute and so forth?

The current 4 minutes 10 seconds (250 seconds) initial Tracker back-off value is still very high.

Regards,

comment:7 Changed 6 years ago by AlderaaN

Bump,

Kindly see post above.

Again, lowering the initial Tracker back-off timeout to 1 minute or less is extremely crucial for those working with Deluge in a SeedBox?-heavy environment, where even the first 30-60 seconds (not minutes) from the moment the client has synced up with the tracker have a huge effect on the seeding ratio outcome.

Regards,

comment:8 Changed 5 years ago by AlderaaN

  • Cc pcfregister@… added
  • Milestone 1.4.0 deleted
  • Status changed from new to pending
  • Version set to 1.3.6

Hello again.

It's been 13 months since I opened this case.

Any chance we'll see this feature implemented in the next release minor release of Deluge?

Regards,

comment:9 Changed 5 years ago by Cas

  • Milestone set to 1.4.0
  • Status changed from pending to assigned

Please do not change ticket details.

It will be implemented along with all the other libtorrent options Plan/libtorrent

comment:10 Changed 5 years ago by AlderaaN

Oops, sorry about that Cas.

Might you have a ETA for such a major release?

Regards,

comment:11 Changed 5 years ago by Cas

No there isn't, there is a lot of work though so months at least.

However there is a plugin for 1.3 users that should be able to control this setting: http://forum.deluge-torrent.org/viewtopic.php?f=9&t=42887

comment:12 Changed 4 years ago by Cas

  • Summary changed from Add support for libtorrent tracker_backoff option to [lt.sess_set.tracker_backoff] Add support for libtorrent tracker_backoff option

comment:13 Changed 7 months ago by Cas

  • Milestone changed from 2.0.x to 2.x

Milestone renamed

Note: See TracTickets for help on using tickets.