Stalled torrents using up queue slots
Stalled torrents using up queue slots
I have queuing setup to have a max of 5 downloads and 10 active torrents.
How do I setup queuing so that a stalled torrent doesn't count towards those limits?
How do I setup queuing so that a stalled torrent doesn't count towards those limits?
Re: Stalled torrents using up queue slots
Settings -> Bittorrent -> "Do not count slow torrents in these limits" and then set that up so it fits your needs.
Re: Stalled torrents using up queue slots
Thanks. I am aware of that setting but it's either unclear, doesn't work properly, or I'm not understanding it. For example I have "max of 5 downloads and a max of 10 active torrents", and have the "Do not count slow torrents in these limits" box checked.
The stalled torrents use up the max active slots.
![Image](http://venus.morante.net/downloads/unibia/screenshots/torrent-slots.jpg)
If I bump up the max active torrents to 40, that opens up more download slots, but again, stalled torrents count towards that:
![Image](http://venus.morante.net/downloads/unibia/screenshots/more-torrent-slots.jpg)
The stalled torrents use up the max active slots.
![Image](http://venus.morante.net/downloads/unibia/screenshots/torrent-slots.jpg)
If I bump up the max active torrents to 40, that opens up more download slots, but again, stalled torrents count towards that:
![Image](http://venus.morante.net/downloads/unibia/screenshots/more-torrent-slots.jpg)
Re: Stalled torrents using up queue slots
I just set it large - about 50.
IIRC years ago slow torrents didn't count towards the maximum (although I might possibly be remembering a different client). I'm guessing it changed to avoid the case where all torrents are active and resources are spread too thinly for anything to be above threshold. I've seen that happen on Azureus and it required manual intervention.
Your values of 5,2,10 don't make much sense either way. In one case you are allowing for only 3 slow torrents, and in the other 10 is greater than 5+2. The point of the old behavior was that you could set something like 5,5,7. When the total active torrents exceeded the limit, seeds would be shut down to allow more upload bandwidth for downloads.
IIRC years ago slow torrents didn't count towards the maximum (although I might possibly be remembering a different client). I'm guessing it changed to avoid the case where all torrents are active and resources are spread too thinly for anything to be above threshold. I've seen that happen on Azureus and it required manual intervention.
Your values of 5,2,10 don't make much sense either way. In one case you are allowing for only 3 slow torrents, and in the other 10 is greater than 5+2. The point of the old behavior was that you could set something like 5,5,7. When the total active torrents exceeded the limit, seeds would be shut down to allow more upload bandwidth for downloads.
Re: Stalled torrents using up queue slots
that's the right behaviour...
source: https://www.libtorrent.org/reference-Se ... tings-packactive_limit is a hard limit on the number of active (auto managed) torrents. This limit also applies to slow torrents.
Re: Stalled torrents using up queue slots
Hello,
I am resurrecting this old thread because I was not able to find the an answer to this question anywhere online and this is the first thread that comes up when searching this problem. Hopefully this helps someone else, this is a throw away account FYI so unlikely I respond to requests for further assistance or questions about this solution. Works for me but not planning to support it.
The reason that I was attempting to do this is that my download machine has limited disk space, an enormous down pipe and a very small up pipe. This system moves files after downloads are complete to a different location for longer term storage and seeding. Because of this I want to queue up 1 torrent at a time, download the contents and then move on down the line. So if 1 torrent is stalled the previous setup required manual intervention by me to return to orderly 1 by 1 processing. This is because the stalled torrent will fill my 1 allowed queue slot forever. Personally I believe this is a libtorrent bug and that the "do not count slow torrents towards these limits" setting should behave as seems logical and exclude stalled torrents from the "active" count.
I solved this by using bash scripting and the qbittorrent webUI API.
Prerequisites
-this is running on ubuntu linux 20 (I am sure you could get it working on windows but that is beyond the scope of my response)
-you will need to parse json so you will need to install jq (sudo apt-get install jq). I am sure there are other ways to do this but I believe this is the most simple.
-you will need to schedule a bash script to run on a recurring basis (I have mine running every 1 minute)
The bash script and line by line explanation.
I am resurrecting this old thread because I was not able to find the an answer to this question anywhere online and this is the first thread that comes up when searching this problem. Hopefully this helps someone else, this is a throw away account FYI so unlikely I respond to requests for further assistance or questions about this solution. Works for me but not planning to support it.
The reason that I was attempting to do this is that my download machine has limited disk space, an enormous down pipe and a very small up pipe. This system moves files after downloads are complete to a different location for longer term storage and seeding. Because of this I want to queue up 1 torrent at a time, download the contents and then move on down the line. So if 1 torrent is stalled the previous setup required manual intervention by me to return to orderly 1 by 1 processing. This is because the stalled torrent will fill my 1 allowed queue slot forever. Personally I believe this is a libtorrent bug and that the "do not count slow torrents towards these limits" setting should behave as seems logical and exclude stalled torrents from the "active" count.
I solved this by using bash scripting and the qbittorrent webUI API.
Prerequisites
-this is running on ubuntu linux 20 (I am sure you could get it working on windows but that is beyond the scope of my response)
-you will need to parse json so you will need to install jq (sudo apt-get install jq). I am sure there are other ways to do this but I believe this is the most simple.
-you will need to schedule a bash script to run on a recurring basis (I have mine running every 1 minute)
The bash script and line by line explanation.
Code: Select all
#replace the values in [] including removing the [] with values that match your instance this line below authenticates with your instance of qbittorrent and may not be needed if you are ignoring auth for local or not using auth
cookie=$(curl -c - --header 'Referer: http://[qbittorrenthost]:[qbittorrentport]' --data 'username=[qbittorrentuser]&password=[qbittorrentpassword]' http://[qbittorrenthost]:[qbittorrentport]/api/v2/auth/login)
#get a list of torrents that are currently stalled and not complete
stallJSON=$(echo "${cookie}" | curl -b - http://[qbittorrenthost]:[qbittorrentport/api/v2/torrents/info?filter=stalled_downloading)
#extract from that list using jq (package must be installed https://stedolan.github.io/jq/) this line looks for torrents where there are 0 seeds and the torrent has been active for at least 1 hour cumulatively. This is designed to give torrents time to get out of a stall and connect to seeds if they exist
hashdropqueue=$(echo "$stallJSON" | jq -r '.[] | select(.num_seeds == 0) | select(.time_active > 3600) | {hash} | join(",")')
#replace spaces between hashes with | for qbittorrent api syntax not sure why join(",") puts spaces between hashes on multiple results but it does and changing to join("|") does not help so this line is necessary for this script to work in the case that multiple torrents are stalled. For me this should not happen since I have my active torrent slots set to 1 but your config may be different
hashdropqueue=$(echo $hashdropqueue | sed 's/ /|/g')
#move down the queue 1 spot all torrents in list that match the above criteria
echo "${cookie}" | curl -b - -X POST http://[qbittorrenthost]:[qbittorrentport]/api/v2/torrents/decreasePrio -d "hashes=$hashdropqueue"
#This line may not be necessary at all (have not tested if changing prio via the api disables auto management) for my setup I want this on you may want to comment out or delete the below line depending on your setup
echo "${cookie}" | curl -b - -X POST http://[qbittorrenthost]:[qbittorrentport]/api/v2/torrents/setAutoManagement -d 'hashes=$hashdropqueue&enable=true'
Re: Stalled torrents using up queue slots
If you need a simple, pythonic and composerized way to achieve this:
https://github.com/blastbeng/qbittorrent_fix_stalled
code example:
https://github.com/blastbeng/qbittorrent_fix_stalled
code example:
Code: Select all
import os
import time
import qbittorrentapi
import datetime as dt
from scheduler import Scheduler
from dotenv import load_dotenv
load_dotenv()
schedule = Scheduler()
def fix_stalled():
conn_info = dict(
host=os.environ.get("HOST"),
port=int(os.environ.get("PORT")),
username=os.environ.get("USER"),
password=os.environ.get("PASS"),
)
qbt_client = qbittorrentapi.Client(**conn_info)
stalled = qbt_client.torrents.info(status_filter="stalled_downloading")
hashdropqueue = []
for torrent in stalled.data:
if torrent.info.num_seeds == 0 and torrent.info.time_active > 3600:
hashdropqueue.append(torrent.hash)
if len(hashdropqueue) > 0:
qbt_client.torrents.decrease_priority(torrent_hashes=hashdropqueue)
schedule.cyclic(dt.timedelta(minutes=90), fix_stalled)
while True:
schedule.exec_jobs()
time.sleep(1)
Re: Stalled torrents using up queue slots
I honestly feel like after so many years of this being an issue, that the developers just refuse to change it to work logically out of spite or something. I mean christ, why is it so difficult to just skip stalled torrents in the queue? why isn't there just a simple check box for that? "If torrent stalled for X minutes, go to next" simple. easy.queuereduce wrote: ↑Mon Jan 16, 2023 4:33 am Personally I believe this is a libtorrent bug and that the "do not count slow torrents towards these limits" setting should behave as seems logical and exclude stalled torrents from the "active" count.
And yet..
Just had to vent. Really hard to believe that this is still an issue in almost 2024, it has been a problem ever since I've been using bitorrent. Why do no clients sort this? Honestly I am asking why such avoidance from an issue that thousands upon thousands of people post and search for online every year is still not fixed?
Gdamn.
Out.
Re: Stalled torrents using up queue slots
I'm curious as to what the actual problem is that can't be solved by setting "Max active torrents" very high.
There are two ways of implementing this:
A. Slow torrents are ignored, and "Max active torrents" is used to drop the number of actively seeded torrents when there are active downloads.
B. Slow torrents count, but "Max active torrents" is just a sanity check.
I liked option A when I was on dial-up and early ADSL, but I don't think it does anything useful anymore. It's also impractical for any client that needs to scale well.
There are two ways of implementing this:
A. Slow torrents are ignored, and "Max active torrents" is used to drop the number of actively seeded torrents when there are active downloads.
B. Slow torrents count, but "Max active torrents" is just a sanity check.
I liked option A when I was on dial-up and early ADSL, but I don't think it does anything useful anymore. It's also impractical for any client that needs to scale well.
Re: Stalled torrents using up queue slots
i also hit this same issue
i think the first problem is that it is not intuitive:
![Image](https://i.imgur.com/0eFMaTH.png)
the boxed out slow torrents section implies that these options are a subset of the above. it implies 'do not count these slow torrents in the above limits', but that's not what happens - 'maximum active torrents' will limit all torrents, even ones that fit into your 'slow' settings. you also can set max active torrents to a lower number than your max downloads or uploads, which seems wrong.
secondly, the defaults are bad. i can't be sure, but i'm pretty sure when i installed qbittorrent from the docker image, it defaulted to a really low number (maybe 5) for maximum active torrents. from what i'm reading in this thread, there's little reason to not set it to a much higher number. perhaps there's no need to have a limit anymore. in any case, the default seems wrong.
i think the first problem is that it is not intuitive:
![Image](https://i.imgur.com/0eFMaTH.png)
the boxed out slow torrents section implies that these options are a subset of the above. it implies 'do not count these slow torrents in the above limits', but that's not what happens - 'maximum active torrents' will limit all torrents, even ones that fit into your 'slow' settings. you also can set max active torrents to a lower number than your max downloads or uploads, which seems wrong.
secondly, the defaults are bad. i can't be sure, but i'm pretty sure when i installed qbittorrent from the docker image, it defaulted to a really low number (maybe 5) for maximum active torrents. from what i'm reading in this thread, there's little reason to not set it to a much higher number. perhaps there's no need to have a limit anymore. in any case, the default seems wrong.
Re: Stalled torrents using up queue slots
I don't think anyone designed the UI badly, almost certainly the behaviour changed in libtorrent and qBittorrent hasn't been updated to reflect that.
perhaps there's no need to have a limit anymore
If slow torrents don't count towards any limit the number of active torrents is unlimited. That's fine for 200 torrents, but maybe not so good for 200,000. My guess is that libtorrent was changed so that there is a limit, allowing clients to scale better. The benefits of the old behaviour are very minor in comparison.
Re: Stalled torrents using up queue slots
And nothing will ever change and people will still be asking for this in 10 years.