349 torrents and no queueing

The music torrent client had 349 torrents in flight. None of them were finishing. All of them were trying to download at the same time. This is what happens when you forget to turn queueing on.

What was happening

CPU on the container was pegged. Network throughput was a fraction of what the link could do. Each torrent was averaging single-digit KB/s. The arr app feeding the client was happily grabbing more releases on its schedule, because nothing was failing — the downloads just weren't progressing fast enough to clear.

qBittorrent > View > Statistics
  Active downloads: 349
  Average per torrent: ~7 KB/s
  Total down: ~2.4 MB/s

A handful of fast torrents would have saturated the link easily. Instead it was death by a thousand cuts.

What I found

Tools > Options > BitTorrent > Torrent Queueing was unchecked. qBittorrent was running every torrent in parallel regardless of how slow they were. The peer connections piled up, the disk thrashed because every torrent wanted a write slot, and the overall throughput collapsed.

This is the same shape as any "no concurrency limit" bug. Five parallel HTTP fetches go faster than 500. A queue depth that exceeds your underlying capacity adds latency without adding throughput.

The fix

Three settings, applied via the qBittorrent web API:

curl -X POST "$QBT/api/v2/app/setPreferences" \
  --data-urlencode 'json={
    "queueing_enabled": true,
    "max_active_downloads": 20,
    "max_active_torrents": 30,
    "dont_count_slow_torrents": true,
    "slow_torrent_dl_rate_threshold": 1024,
    "slow_torrent_inactive_timer": 300
  }'

Translated: - Queue is on. - Up to 20 actively downloading torrents at a time. - Up to 30 active torrents total (downloading + seeding combined). - A torrent with under 1 KB/s for more than 5 minutes doesn't count against the active slot — it gets rotated out for a queued one.

Result: the active 20 actually got bandwidth. Slow ones rotated out. Within a few hours the queue had drained meaningfully and new album imports were landing in waves.

What I'd do differently

Whenever I provision a new qBittorrent instance from scratch, I now have a small bootstrap script that sets these queueing defaults along with the other reasonable settings (alt-bandwidth schedule, port from VPN config, default save paths). Default qBittorrent is configured for a power user who'll tune it themselves. Default-for-a-headless-arr-stack-client is a different default, and writing it down in a script means I don't ship a misconfigured client to myself ever again.