You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some torrent trackers, especially those used for private torrents, establish a limit on how many torrents can be downloaded at the same time. However, sometimes seeds are not connected or there are no seeds at all. Imagine a scenario with a limit of 10 active torrents established in the tracker (at the 11th torrent it will fail with an error message saying that the torrent limit has been reached). Imagine the user has 200 torrents from this tracker and 60% of the torrents currently have no seeds.
The current queue management does not take into account trackers or possible limits established by these or the fact that all trackers of a torrent might be returning an error.
If 10 first torrents have no seeds, they will remain as stalled. And the other 190 will try to download but they will receive an error from the tracker and this would lead to a quasi-deadlock situation.
If I set the download limit to 10, it will also not work because stalled torrents will always count and will never be auto-paused.
What is the expected behavior
Being able to mark torrents in a way so if they are "stalled" for more than X minutes, they go to the back of the queue. This would be the easiest solution. Could be also a global setting.
The more complex solution would be to be able to establish the limit of torrents per tracker and if the limit is reached and torrents are stalled, the queue would somehow allow qBittorrent to try to queue the stalled ones and try to see if there are sources for any of the others using the same tracker exclusively.
I think the first option is quite straightforward and it will help people with torrents that are stalled for years until finally a seed resuscitates.
Steps to reproduce
Disable the option of ignoring slow downloads from the download count (you cannot do this with the private tracker with limits, because qBittorrent will activate ALL other torrents without pausing or queuing the stalled ones).
Put N torrents without seeds at the top of your queue, establish a limit of active downloads to N/2. Add more torrents with seeds with lower priority. The ones with seeds will never download.
The text was updated successfully, but these errors were encountered:
hades646
changed the title
Queue management: limited private tracker when there are many torrents without seeds leads to-> deadlock
Queue management: limited private tracker when there are many torrents without seeds leads to a deadlock
Jan 20, 2021
I have not experienced this in my decades of torrenting but it seems like a tracker issue. Those tracker limits only work on downloads and torrents without seeds are not downloading and should therefore not triggering the trackers limits.
As long as the torrent is active, the tracker treats it as such. Only when
you pause it it stops being counted.
I've only experienced this problem with closed torrenting communities,
where the link to the tracker contains an ID or hash linked to your user.
I think dead queue rotation is a good idea anyways, maybe one day you'll be
lucky and one of the active torrents will download.
El lun., 22 feb. 2021 0:24, The5kull <notifications@github.com> escribió:
I have not experienced this in my decades of torrenting but it seems like
a tracker issue. Those tracker limits only work on downloads and torrents
without seeds are not downloading and should therefore not triggering the
trackers limits.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#14261 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADSRFDBWTMGABB4MSDZBFALTAGIZDANCNFSM4WLBIESQ>
.
Please provide the following information
qBittorrent version and Operating System
4.3.3
What is the problem
Some torrent trackers, especially those used for private torrents, establish a limit on how many torrents can be downloaded at the same time. However, sometimes seeds are not connected or there are no seeds at all. Imagine a scenario with a limit of 10 active torrents established in the tracker (at the 11th torrent it will fail with an error message saying that the torrent limit has been reached). Imagine the user has 200 torrents from this tracker and 60% of the torrents currently have no seeds.
The current queue management does not take into account trackers or possible limits established by these or the fact that all trackers of a torrent might be returning an error.
If 10 first torrents have no seeds, they will remain as stalled. And the other 190 will try to download but they will receive an error from the tracker and this would lead to a quasi-deadlock situation.
If I set the download limit to 10, it will also not work because stalled torrents will always count and will never be auto-paused.
What is the expected behavior
Being able to mark torrents in a way so if they are "stalled" for more than X minutes, they go to the back of the queue. This would be the easiest solution. Could be also a global setting.
The more complex solution would be to be able to establish the limit of torrents per tracker and if the limit is reached and torrents are stalled, the queue would somehow allow qBittorrent to try to queue the stalled ones and try to see if there are sources for any of the others using the same tracker exclusively.
I think the first option is quite straightforward and it will help people with torrents that are stalled for years until finally a seed resuscitates.
Steps to reproduce
Disable the option of ignoring slow downloads from the download count (you cannot do this with the private tracker with limits, because qBittorrent will activate ALL other torrents without pausing or queuing the stalled ones).
Put N torrents without seeds at the top of your queue, establish a limit of active downloads to N/2. Add more torrents with seeds with lower priority. The ones with seeds will never download.
The text was updated successfully, but these errors were encountered: