I recently switched over from uTorrent to qBT using the Ruby on Rails script which worked great. Cudo's to the author of that.
I made the switch because I have over 6000 torrents that I seed to 3-4 private sites and I reach some sort of limit in uTorrent which I could not get past.
So my issue is that I really want to restrict my "Active Torrents" to 20 or so, yet the Torrent Queueing settings under the Bittorrent section has limits that cause me issues. The Maximum active torrents can only go up to 999, so that puts 5000+ torrents in a queued state which is not good where bonus points are given for seeding, and the queue status seems to make them not visable from I can tell.
So I currently have that option turned off, and at any given time I have 200-250 "active uploads" which is way too much, and reduce the bandwidth to nothing for those connected.
So my question is whether we can get the Maximum active torrents increased in a future release of the UI or is there a settings file I can edit to override this?
I really want to provide connected users with better bandwidth, but this seems to be the only way to control the limits. Am I missing something or is my understanding of the "Queued Status" of a torrent wrong? Looking for some guidance here.
SM
Questions on setting "Torrent Queueing" to control "Active Uploads"
Re: Questions on setting "Torrent Queueing" to control "Active Uploads"
qBitTorrent's Torrent Queueing seems to be buggy even when dealing with 100-1000 torrents.
You could try setting Global max and per torrent upload slots low enough to not cause problems even with no active torrent limits.
Give each upload slot about 5-10 KiB/s of your total upload speed.
So if you have 1000 KiB/s usable upload speed, that would mean 100-200 global upload slots and probably only 2-10 upload slots per torrent. There is still minor problems limiting torrents to only 1 upload slot, so that's why I used 2 as a minimum.
You could try setting Global max and per torrent upload slots low enough to not cause problems even with no active torrent limits.
Give each upload slot about 5-10 KiB/s of your total upload speed.
So if you have 1000 KiB/s usable upload speed, that would mean 100-200 global upload slots and probably only 2-10 upload slots per torrent. There is still minor problems limiting torrents to only 1 upload slot, so that's why I used 2 as a minimum.
Re: Questions on setting "Torrent Queueing" to control "Active Uploads"
Thanks, I'll give it a try and see how it works. Will report back. When you say Torrent Queueing has problems in general, what are the chances this is something being looked at and would see a fix in the near future?
Being a noobie, I have no idea how responsive the development community is for qBt
SM
Being a noobie, I have no idea how responsive the development community is for qBt
SM
Re: Questions on setting "Torrent Queueing" to control "Active Uploads"
It's being looked at, but part of the problem is how qBitTorrent counts started torrents for purposes of downloading, seeding, and "stalled" torrents.
Torrents can be "stalled" and still count against the queue limits.
Many torrents have more than 1 tracker, by default or added by users, but some of the trackers may be dead/offline/overloaded/etc. If all the trackers contacted are in an error state, the torrent may still count against the max torrent limits but not be doing anything. While the solution may seem to be to always announce to every tracker, some trackers ban BitTorrent clients that announce too often -- and that includes if they announce to the tracker's secondary URLs in a short time interval (like <1 hour). This is especially bad if the tracker has https alternates, which are almost always only meant to be used as a last resort.
So the few remaining "big" working trackers are sometimes getting overloaded and the little trackers that get added to too many torrents die as the people running them cannot afford the bandwidth bills.
...which means more-and-more torrents are left in a "stalled" state because they can't find peers/seeds.
DHT, PEX, and LSD are alternate methods to trackers to find other peers/seeds.
...but PEX can't work unless it connects to at least 1 working peer or seed that has ip lists for other peers/seeds.
LSD typically can't search further than the same LAN or local node of your ISP. It can incorrectly labels peers/seeds as "local" (on the same LAN and ignore speed limits) when they're not.
And DHT has some problems if qBitTorrent's incoming connection is firewalled.
Connectivity comes at a cost -- there has to be a common location peers/seeds can "phone home" to...in order for them to find one another. (Even DHT has to bootstrap.)
On top of this, torrents can fail due to running out of storage space where they're saved...or they're overwritten by another torrent using the same filenames at the same time...or lacking write permissions...or pathnames too long...or drive failures, etc. These will all mess torrent queueing up badly and needs a lot of manual control to fix the problems -- qBitTorrent at best can only warn that these problems happen.
The developers/programmers for qBitTorrent are pretty busy right now fixing lots of minor-to-major issues -- Webui seems to be getting a massive rebuild.
But at least 1 has looked recently at torrent queueing issues.
Have you checked qBitTorrent's issues forum at github? at: https://github.com/qbittorrent/qBittorrent/issues
...to see if the exact issues are being covered? And make a new post there if not!
And if you're feeling really brave, try studying qBitTorrent's sourcecode for problem causes.
Torrents can be "stalled" and still count against the queue limits.
Many torrents have more than 1 tracker, by default or added by users, but some of the trackers may be dead/offline/overloaded/etc. If all the trackers contacted are in an error state, the torrent may still count against the max torrent limits but not be doing anything. While the solution may seem to be to always announce to every tracker, some trackers ban BitTorrent clients that announce too often -- and that includes if they announce to the tracker's secondary URLs in a short time interval (like <1 hour). This is especially bad if the tracker has https alternates, which are almost always only meant to be used as a last resort.
So the few remaining "big" working trackers are sometimes getting overloaded and the little trackers that get added to too many torrents die as the people running them cannot afford the bandwidth bills.
...which means more-and-more torrents are left in a "stalled" state because they can't find peers/seeds.
DHT, PEX, and LSD are alternate methods to trackers to find other peers/seeds.
...but PEX can't work unless it connects to at least 1 working peer or seed that has ip lists for other peers/seeds.
LSD typically can't search further than the same LAN or local node of your ISP. It can incorrectly labels peers/seeds as "local" (on the same LAN and ignore speed limits) when they're not.
And DHT has some problems if qBitTorrent's incoming connection is firewalled.
Connectivity comes at a cost -- there has to be a common location peers/seeds can "phone home" to...in order for them to find one another. (Even DHT has to bootstrap.)
On top of this, torrents can fail due to running out of storage space where they're saved...or they're overwritten by another torrent using the same filenames at the same time...or lacking write permissions...or pathnames too long...or drive failures, etc. These will all mess torrent queueing up badly and needs a lot of manual control to fix the problems -- qBitTorrent at best can only warn that these problems happen.
The developers/programmers for qBitTorrent are pretty busy right now fixing lots of minor-to-major issues -- Webui seems to be getting a massive rebuild.
But at least 1 has looked recently at torrent queueing issues.
Have you checked qBitTorrent's issues forum at github? at: https://github.com/qbittorrent/qBittorrent/issues
...to see if the exact issues are being covered? And make a new post there if not!
And if you're feeling really brave, try studying qBitTorrent's sourcecode for problem causes.