Piracy: ꜱᴀɪʟ ᴛʜᴇ ʜɪɢʜ ꜱᴇᴀꜱ

I'm not actually an expert on the matter, and there is probably someone who knows more.

There are 2 protocols that qbittorrent uses for data sharing. The oldest one is basic TCP, with the same overhead. The "newer" (it's already quite old, too) protocol is µTP. It was specifically designed for p2p purposes, specifically torrents. µTP is, among other things, designed to coexist with other traffic without slowing it down. For this purpose, its packet size is variable. On very small packets, the overhead is big, while on larger packets it's small. I don't know how different the average overhead is between the 2 protocols, since those variable packets were designed for shared ADSL. Modern broadband probably allows µTP to use bigger packets most of the time.

From what I can gather, encryption also adds overhead to the traffic.

This is, however, not the main source of overhead (I don't even know if that overhead is really counted, I'd have to look more into it). The main source of overhead is actually control traffic (and that's the reason why you get download even when only uploading). Peers constantly communicate with each other to form the swarm, and they need to request blocks and announce which blocks they have. As far as I understand, this is the main source of the overhead, and it's independent from the protocol. Your client will announce to other peers what pieces it has, and its capabilities.

I also don't know if tracker traffic is included in the count. Your client sends a status to trackers every n minutes, which are specified by the tracker. Those are called announces. Most trackers have announce times between 30 minutes and 1h. If you have 500 torrents, with an average of 5 trackers per torrent and an average announce time of 45 minutes, you're sending ~3.3k announces per hour. They don't take much, but they add up.

DHT and PeX traffic could also be counted, but as with trackers, I don't know if it is.

If you start trying to get higher and higher ratios, you'll notice there's an asymptotic curve the higher you go. It really seems impossible to get to 30. I once had a client lose its historical up/down data, and without any download, it stopped at a ratio of around 32. This may be the ratio between upload + upload overhead / download overhead (from the PoV of your client).

Now, while I don't have any proof and I don't know how qbittorrent counts overhead, I suspect all those overheads are counted at the same time. So you're basically stacking them. This is because of the traffic limiter. If you really want to limit traffic to 100mbps, ideally, you'd count every overhead. If you don't, you could end up with both an unpredictable amount of traffic, and a higher amount of it than 100mbps. If they already implemented a counter that considers all overhead (basically just counting raw packet data), it would make sense that they used it for the global traffic counter.

Yep. Fully dubbed in german and in very decent quality :)

Ahhh thank you for brightening my day 😍

Then start hardlinking instead of moving.
(at least if it's the same storage volume)

Its likely because your VPN is disconnecting and qbit isnt getting restarted when it happens so it just sits there without being able to connect. Adding deunhealth to your stack and having it monitor qbit can help