qBittorrent official forums

I have never gone above 1000 because somebody told me that's the most qbittorrent can handle. Certainly it gets really messy sometimes after a crash, so I'm thinking that if I need to manually keep track on what I'm actually seeding then I can't go above 1000 it's just too unruly.

What are other people's experience and what's the recommended maximum?

RAM has very little to do with anything, as qBT is a 32bit application so can only use 2GiB of memory at maximum and WILL crash long before it gets to that, and on Windows running ANY BT client with more than around 50 active jobs is asking for trouble.
Yes I know it can be done but it's hardly reliable.

If you want to run 100+ jobs reliably, get a Linux box with Centos 6 or Ubuntu 12.04  (LTS distro) on it. If you need a "pointy clicky" interface LXDE or KDE are about the easiest for Linux 'newbs' to get used to.

[quote="ciaobaby"]
RAM has very little to do with anything, as qBT is a 32bit application so can only use 2GiB of memory at maximum and WILL crash long before it gets to that, and on Windows running ANY BT client with more than around 50 active jobs is asking for trouble.
Yes I know it can be done but it's hardly reliable.

If you want to run 100+ jobs reliably, get a Linux box with Centos 6 or Ubuntu 12.04  (LTS distro) on it. If you need a "pointy clicky" interface LXDE or KDE are about the easiest for Linux 'newbs' to get used to.
[/quote]

By "jobs", do you mean 50 active torrents seeding? i'm seeding nearly 400 of them right now on a fiber optic line (10mbit up). I upped 50 GB in a bit more 30 hours with a speed limit set on 800KB/s. The client is Deluge (1.3.6 with libtorrent 0.16.16) on an old C2D with Win 7 X86 and 3GB of ram. qBt has WebUI problems right now...Especially with Transdroid so i can't use it. Deluge also has label support and recheck files in Transdroid which is reaaally nice.

Anyway, i managed to seed up to 500+ torrents with qBt. It obviously has a slow startup with that many torrents but it's stable.

It is not the clients that  are the problems, they are just the catalyst for other Windows problems.

Some fixes that might interest you (planned for v3.1.10)
1. https://github.com/qbittorrent/qBittorr ... 188dc1e0ae
2. https://github.com/qbittorrent/qBittorrent/issues/1668

[quote="ciaobaby"]
It is not the clients that  are the problems, they are just the catalyst for other Windows problems.
[/quote]

Well honestly, i didn't notice any unusual problems on my computer...

Having problems isn't guaranteed, it will depend on many other factors, there isn't a "one size fits all" scenario.

Single file payloads jobs use less system resources (such file handles), so running several hundred may create no problems at all, whereas multiple file payloads (that includes 'split' archives) may trigger Windows "runaway caching"  with only twenty or thirty such jobs.

Okay i see. I do have a ton of torrents with multi-part archives. I also have an enormous arcade rom collection containing 28,000 files. It did freeze qBt and Deluge when i added this one. It improved a lot since qBt 3.0 though.

So based on that, your jobs are not particularly 'active'. (which is when  problems would start appearing).

Disclaimer: The following is a general comment for ANYONE reading this thread.

There is ABSOLUTELY no point whatsoever in using 'multi-part' archives for BitTorrent protocol transfers, it is not needed, it is NOT necessary. The BitTorrent protocol does the "splitting", that is what 'pieces' are. BitTorrent is NOT like HTTP or FTP that starts the transfer and continues until the correct number of bytes in the monolithic payload have been transferred, and any connection breaks or interruptions mean that the transfer may have to start  again from byte 0, the  BitTorrent protocol was developed  to mitigate such  problems of large file transfer over unreliable connections ( https://wiki.theory.org/BitTorrentSpeci ... tification ).
Splitting monolithic archives for BTP client transfers can (that's CAN not DOES) create additional, unnecessary overhead and does use additional resources (file references and handles) on  peers that are in the swarm.

As your mother probably told you, .... It's not 'big' and it's not clever.

(Disclaimer ends)

I understand what you're saying, but it's not up to us if it's split archived or not.

Yep, that's why I said it was added as a general comment thereby indicating it is not particularly germane to this  conversation but it is related, should anyone read this thread in the future.

Thanks for clarifying the relationshsip between qbittorrent and RAM, ciaobaby.

Well I am seeing on some private trackers, people boasting about seeding 2000 book torrents on one particular tracker, for example, then 500 films and 1000 albums on a music tracker....

And I am thinking "what software are they using.... not qbt, I guess, at least!

And I also recall seeing a discussion about how much you can seed in qbt, and several people saying "don't go above 1000" without being too specific about why not.

I have actually been up att perhaps 1050, but normally I just drop a few as I add more, so I always stay below 1000.

I was thinking that maybe it's not needed and QBT can in fact handle much more than I'm letting it try....

For sure, it takes a while longer to start, but compared with a year ago, I think QBT is more stable, starts faster and less prone to crashes. When it does crash it doesn't go into a fit like it did before, but as of a few months back it remembers what it was seeding, and where, and more or less continues where it left off. Phew!

Maybe it's ready to be stretched a bit more? Above 1000 seeding torrents?

I think they say that because the GUI becomes laggy.
Pay close attention to this: https://github.com/qbittorrent/qBittorrent/issues/1668 Look at its numbers. When the changes are finalized and merged the GUI shouldn't be laggy anymore (and the CPU usage should be minimal)
Also I'll need to implement these 2 for 3.1.10
1. https://github.com/qbittorrent/qBittorrent/issues/1698
2. https://github.com/qbittorrent/qBittorrent/issues/1699

And I am thinking "what software are they using.... not qbt, I guess, at least!

It's not necessarily the client, but the operating system.

uTorrent server (Linux only) will happily run many hundreds of jobs, well, once you get past it being overly fussy about what libraries are installed that is. While uTorrent on Windows will get 'flakey' if it is running 20+.

For Windows clients don't use the number of running jobs as the absolute criteria for determining what is a 'safe' limit, the total number of individual 'open' files that are encapsulated in the payloads is what will bring Windows "to it's knees".
ie: If a torrent payload has ten files in and each one of those files has one active 'piece'. To the BT client that is one job with ten connections. To Windows it is TEN open files that has to have cache space reserved, plus any files that the client has open such as configuration files, the meta data file(s), DLLs etc.

Yet ANOTHER reason to migrate to Linux once and for all then. I didn't realise it was such a big difference. Thanks Ciao for explaining.

Ok Sledgehammer I will keep an eye on the thread for the improvements.

Thanks for the fantastic work over the last year with QBT! It's so much more stable now than before. I can't believe people are still using ad-ridden, proprietary junk like uTorrent when qbt is around. Even on Windows its miles ahead.
I'm so glad I migrated now.