Tracker Priority Order

[metaclam]

​https://forum.transmissionbt.com/viewtopic.php?f=3&t=11199

I have one dream feature request: a priority order for trackers.

The idea is simple: list trackers in order of priority. If there are seed requests from high priority trackers, anything on low priority trackers would either pause or go down to a set "trickle" (5K, 10K) total for those low priority trackers.

Right now I have to manually set upload limits for each torrent on these low priority trackers to 5K each. But when there's nothing going to high priority trackers, there's no reason to limit those in that way (as there's bandwidth to spare).

In other words, I have torrents on trackers which will always suck up 100% of my bandwidth and I want them to automatically pause (or significantly slow) to make room for the high priority trackers.

========

The request is about allocating upload bandwidth to peers from one tracker over another. That would be handled in bandwidth.c, peer-io,c, and peer-manager.c.

[livings124]

How would this work with transfers with multiple trackers?

[jordan]

I'm not quite sure how to implement this, but I would use it too.

[metaclam]

The way I see it working is you can enter a list of tracker domains. (ie, demonoid.me) For each one you can specify a priority of high, medium, and low. For each priority you can specify a cap (as you can for individual torrents). If any transfer on a higher priority tracker is active, the lower priority trackers would fall to their total caps, so that any transfers for those lower priority trackers would have their bandwidth divided by the cap.

For example, lets say you set "high" to unlimited, "medium" to 30 kpbs and low to 0. If there were no tranfers on high priority trackers and 2 on medium, all transfers on low priority trackers would stop (0), and the medium would get full available bandwith. (each transfer taking half of available.)

If there were 2 transfers on high priority trackers and 3 on medium, then each one on medium would get 10 kbps each, and the 2 on high would get the remainder of the available bandwidth, and any on low would stop. if there were none on high or medium, any on low would divide all available bandwidth.

individual torrent caps would still apply only after those tracker priority rules applied. so if you capped a torrent on a low priority tracker at 5 kpbs, and there were no transfers on medium or high trackers, then that one torrent would still get 5 kbps and any others going on low trackers would divide remaining available bandwidth.

As far as "transfers with multiple trackers" -- I suppose it would work just fine if that transfer contained any priority-listed tracker to treat it at that priority for all trackers. Maybe it's possible to treat each tracker separately within that transfer but I don't know about that.

I hope this makes good sense!

[jordan]

Oh, it does. I would prefer to give priority to torrents from fedora's tracker and crunchbang's tracker than to linuxtracker.org.

What I meant was I'm unsure of the best way to code it. I should have been clearer about what I meant :)

[metaclam]

I've outlined the logic. It's just a rules system and shouldn't be any harder to program than the current individual torrent caps or the global limits.

To my mind the harder issue is how to fit it in the GUI. One possibility might be instead of "tracker" priority (which would be my preference) you made use of Groups. That may require some people to reorganize groups a little. But then you could just have:

a) a high/medium/low priority pull-down menu on each group's pane.

b) 3 more fields on the bandwidth tab for "Group bandwidth limits" (With a tool tip/explanation like: "Applies when there are active torrents in higher priority groups")

If you stuck with the tracker idea instead of groups, then you'd need another tab for trackers that would look similar to groups. With the auto-assign functionality of groups, that might not be needed. I mainly use the groups for trackers anyway.

[livings124]

This sounds awfully confusing to me. Few people would use this, and it would make the ui much more complicated.

[metaclam]

how do you know few people would use this? have you taken a poll? The one other user on trac wants it, and before the forum thread was thinned, several others also supported the idea:

​https://forum.transmissionbt.com/viewtopic.php?f=3&t=11199

I think it would be useful to just about everyone who uses any quota based trackers, which is in turn is a significant portion of serious torrent users. Some sites where you have extremely high ratios will suck all your bandwidth 24/7, and some sites where you need to boost your ratio will only get requests infrequently. The latter are thus high priority.

To my mind the lack of being able to control that is the greatest missing feature of torrent clients and pretty much the most obvious thing that should be implemented.

2) it's hardly confusing. I laid out the logic I think quite well, and if you use Groups instead of trackers, you need exactly 4 new interface elements.

[Nemo_bis]

I may use something like this too, but I agree with livings124. We have per-torrent priority, you only have to set it with your own criteria, which happen to be their tracker. A sensible enhancement request would be something that facilitates that, i.e. the ability to sort torrents by tracker (or by private vs. non private) or to show the tracker name in non-compact view.

[Nemo_bis]

And the latter was done in 2.82 (14160), I just noticed: there is a dropdown to filter torrents by tracker.