Hmm, DHT and PEX are enabled by default on qBittorrent, Deluge and Transmission, but should be about finding peers only, not about whether download really starts or not.
Currently not sure what the percentage on connected peers mean, but I guess it is about how much of the file was downloaded from that peer, at least that would make sense.
USB boot is generally unrelated, this is a pure userland issue. NTFS drive could be related indeed, since NTFS is not natively supported by Linux, but coming with next Linux LTS version: https://github.com/MichaIng/DietPi/issues/5129
Until then, NTFS with ntfs-3g driver (for emulated UNIX permissions and partial symlink support) implies high CPU load in I/O which may have an effect on download speeds.
Transmission runs into a segmentation fault, which generally means an unallowed memory access. This can be a bug in the binary (which is somehow unexpected with the ARMv8 image, using native Debian builds which are expected to be stable) or a limitation related to filesystem access, possibly related to NTFS, but not sure.
You do forward the DHT and peer listening ports, don’t you? Can be checked via ss -tulpn, which is AFAIK:
- qBittorrent: 6881 and above, 6881 - 6889 AFAIK
- Deluge: 6881 - 6891
- Transmission: 51413
- rTorrent: 49164
- UDP port 6881 is usually used for DHT, in case of rTorrent, qBittorrent definitely.
We should actually align this, using a single defined peer listening port for all BitTorrent servers/clients we offer.