"Maximum active torrents" and "Maximum active uploads" options seem to do the same thing #10099

Closed
opened 2026-02-21 20:34:03 -05:00 by deekerman · 3 comments
Owner

Originally created by @j03bj03 on GitHub (Apr 5, 2020).

Hello,

I am splitting issue https://github.com/qbittorrent/qBittorrent/issues/12310 into 2 issues / bugs, because after trying to reduce the number of torrents uploading at the same time, I found 2 distinct issues.

qBittorrent version and Operating System

qBittorrent 4.2.1 64-bit
Windows 7 Ultimate (6.1.760x)

What is the problem

The options named "Maximum active torrents" and "Maximum active uploads" seem to do the exact same thing.

###Other informations
What I wanted was to keep all my torrents available for seeding (active) while limiting the number that are uploading at the same time, because on peak hours, qBittorrent crashes when the demand is too high. I thought setting "Maximum active torrents" to -1 and "Maximum active uploads" to 20 would do this. However, after a restart, qBittorrent had randomly chosen 20 torrents to keep on "Seeding" status and all the other were on "Queued" status.

The exact same behavior happens when I set "Maximum active torrents" to 20 and "Maximum active uploads" to -1. All my torrents except 20 become on "Queued" status.

These 2 behaviors almost insure that I stop uploading at all, because qBittorrent does not choose "wisely" which ones should be on "Seeding" and which ones should be on "Queued". It's just random, so most likely the 20 chosen don't have a demand at the moment they are "Seeding".

Originally created by @j03bj03 on GitHub (Apr 5, 2020). Hello, I am splitting issue https://github.com/qbittorrent/qBittorrent/issues/12310 into 2 issues / bugs, because after trying to reduce the number of torrents uploading at the same time, I found 2 distinct issues. ### qBittorrent version and Operating System qBittorrent 4.2.1 64-bit Windows 7 Ultimate (6.1.760x) ### What is the problem The options named "Maximum active torrents" and "Maximum active uploads" seem to do the exact same thing. ###Other informations What I wanted was to keep all my torrents available for seeding (active) while limiting the number that are uploading at the same time, because on peak hours, qBittorrent crashes when the demand is too high. I thought setting "Maximum active torrents" to -1 and "Maximum active uploads" to 20 would do this. However, after a restart, qBittorrent had randomly chosen 20 torrents to keep on "Seeding" status and all the other were on "Queued" status. The exact same behavior happens when I set "Maximum active torrents" to 20 and "Maximum active uploads" to -1. All my torrents except 20 become on "Queued" status. These 2 behaviors almost insure that I stop uploading at all, because qBittorrent does not choose "wisely" which ones should be on "Seeding" and which ones should be on "Queued". It's just random, so most likely the 20 chosen don't have a demand at the moment they are "Seeding".
deekerman 2026-02-21 20:34:03 -05:00
  • closed this issue
  • added the
    Core
    label
Author
Owner

@thalieht commented on GitHub (Apr 5, 2020):

It's just random, so most likely the 20 chosen don't have a demand at the moment they are "Seeding".

This is what the "Do not count slow torrents in these limits" option is for.

@thalieht commented on GitHub (Apr 5, 2020): >It's just random, so most likely the 20 chosen don't have a demand at the moment they are "Seeding". This is what the "Do not count slow torrents in these limits" option is for.
Author
Owner

@j03bj03 commented on GitHub (Apr 5, 2020):

@thalieht Thank you for answering, but the option you are talking about is not related to the issue here. I have 2KB/s set in "Do not count...", but still, as soon as I limit either active torrents or active uploads, let's say max 20, all my torrents except 20 become "Queued" and stop. The option "Do not count..." also is not related at all with limiting the number of torrents uploading or active. Setting this option will not help in specifying an exact number of active torrents/uploads or connections.

@j03bj03 commented on GitHub (Apr 5, 2020): @thalieht Thank you for answering, but the option you are talking about is not related to the issue here. I have 2KB/s set in "Do not count...", but still, as soon as I limit either active torrents or active uploads, let's say max 20, all my torrents except 20 become "Queued" and stop. The option "Do not count..." also is not related at all with limiting the number of torrents uploading or active. Setting this option will not help in specifying an exact number of active torrents/uploads or connections.
Author
Owner

@xavier2k6 commented on GitHub (Mar 16, 2025):

This ticket has been closed.


Closure Reason: being "out-of-date", and thus either most likely resolved in recent versions or no longer applicable.


  • If you experience the reported problem or similar in the latest version, please open a new issue report with the requested information in the issue template.

  • Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar.

  • Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression.

  • A new issue report with relevant updated data gathered from the latest version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression.

  • Thank you for your contribution(s).

@xavier2k6 commented on GitHub (Mar 16, 2025): ### This ticket has been closed. ____ **Closure Reason: being "out-of-date", and thus either most likely resolved in recent versions or no longer applicable.** ____ * If you experience the reported problem or similar in the **latest** version, please open a new issue report with the requested information in the issue template. * Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar. * Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression. * A new issue report with relevant updated data gathered from the **latest** version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression. * Thank you for your contribution(s).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/qBittorrent#10099
No description provided.