Download speed priority for torrents #14922

New issue

Closed

opened 2026-02-22 01:34:32 -05:00 by deekerman · 4 comments

deekerman commented

2026-02-22 01:34:32 -05:00

Owner

Originally created by @DarkVoyage on GitHub (Aug 31, 2023).

Suggestion

Sounds as simple as it is.

Use case

Depending on a set speed priority torrent will get more or less part of available speed. This feature exists in uTorrent and works exactly as expected. Torrent with higher priority would significantly boost over all others (of course if seed offers more speed).

Realization is simple. All torrents are normal by default. If you set some torrent to high, all other downloading torrents are limited to 10% (can be configured?) of average speed (during some period, i.e. minute). If you set torrent to low it sets to 10% of average. If there's a mix of all three, then set all normal to 10% and low to 1% of average.

Average global speed is not good in a case, when prioritized torrent is not downloading and speed will always fall for the lower priority until it reaches 0. But at same time it guarantees you don't use more of channel width that you have.

Channel width detection strategy may be different. You can test speed from time to time or use a preset value.

Extra info/examples/attachments

No response

Originally created by @DarkVoyage on GitHub (Aug 31, 2023). ### Suggestion Sounds as simple as it is. ### Use case Depending on a set speed priority torrent will get more or less part of available speed. This feature exists in uTorrent and works exactly as expected. Torrent with higher priority would significantly boost over all others (of course if seed offers more speed). Realization is simple. All torrents are normal by default. If you set some torrent to high, all other downloading torrents are limited to 10% (can be configured?) of average speed (during some period, i.e. minute). If you set torrent to low it sets to 10% of average. If there's a mix of all three, then set all normal to 10% and low to 1% of average. Average global speed is not good in a case, when prioritized torrent is not downloading and speed will always fall for the lower priority until it reaches 0. But at same time it guarantees you don't use more of channel width that you have. Channel width detection strategy may be different. You can test speed from time to time or use a preset value. ### Extra info/examples/attachments _No response_

deekerman

2026-02-22 01:34:32 -05:00

closed this issue
added the
Feature request

Duplicate
labels

deekerman commented

2026-02-22 01:34:47 -05:00

Author

Owner

@thalieht commented on GitHub (Aug 31, 2023):

Duplicate of #566

@thalieht commented on GitHub (Aug 31, 2023): Duplicate of #566

deekerman commented

2026-02-22 01:34:49 -05:00

Author

Owner

@DarkVoyage commented on GitHub (Aug 31, 2023):

Wow, 2013! Looks like I finally hit something needed by many, not just me...
And the side about upload speed priority explained in 2013 is what I completely missed from my speech. Support that completely! But that would better be configured not individually, but inside categories. You go into setting of category and set upload priority to high for whole set of torrents. And that is better that you don't need to set that individually for each new torrent, but will apply to everything going into that category.

@DarkVoyage commented on GitHub (Aug 31, 2023): Wow, 2013! Looks like I finally hit something needed by many, not just me... And the side about upload speed priority explained in 2013 is what I completely missed from my speech. Support that completely! But that would better be configured not individually, but inside categories. You go into setting of category and set upload priority to high for whole set of torrents. And that is better that you don't need to set that individually for each new torrent, but will apply to everything going into that category.

deekerman commented

2026-02-22 01:34:49 -05:00

Author

Owner

@luzpaz commented on GitHub (Aug 31, 2023):

@thalieht should we close in favor of #566 then ?

@luzpaz commented on GitHub (Aug 31, 2023): @thalieht should we close in favor of #566 then ?

deekerman commented

2026-02-22 01:34:49 -05:00

Author

Owner

@thalieht commented on GitHub (Sep 1, 2023):

Yeah. I changed the title of that issue because no one would find it by searching. If you can think of something more... searchable, feel free to change it.

@thalieht commented on GitHub (Sep 1, 2023): Yeah. I changed the title of that issue because no one would find it by searching. If you can think of something more... searchable, feel free to change it.