qBitTorrent won't download anything and transmission keeps failing

Troubleshooting
1

I have recently acquired a Raspberry Pi 4B (4GB) and I’ve done following to set it up :

  1. Installed the ARMv8 64-bit image on it using a USB boot
  2. Did a complete headless setup with a static IP and wireless connection
  3. Mounted an external NTFS HDD using dietpi-drive_manager
  4. Installed qbittorrent, deluge and transmission on it using dietpi-softwares

With all this done, I am running into several problems with all the torrent clients

  • qBittorrent & deluge
    The files simply won’t download. I managed to download one torrent using qBittorrent. Suddenly after that it doesn’t download any other torrent. I added the Ubuntu LTS torrent to test and it shows me the number of seeds and peers in the client. It initially shows the peers connected like 3(500) but nothing actually downloads. There’s no upload or download at all. I have provided permissions to the download directory using dietpi-explorer. The same happens with deluge.

Additionally I’ve observed that all the peers listed under “peers” are at status 0%. I see none of the connected peers at 100% though the same torrent downloads at around 13MBps on my windows laptop.

  • transmission
    Since qBittorrent and deluge weren’t working, I went to transmission. Surprisingly, transmission could download the same torrent. The speed wouldn’t go beyond 3.2 MBps but at least it could download a few files. What could be causing the slow speeds ? Is it the USB boot ? NTFS harddrive ? Further, the biggest problem I face with transmission is that it randomly stops working. The service randomly fails. Under dietpi-services, it shows me “failed” for transmission-daemon. I went through some threads that suggest reducing the max cache to a smaller number. I tried that as well and the transmission-daemon still fails. Based on one of the threads, I ran
 journalctl -u transmission-daemon

and it gave me following at the bottom with one of the torrents :

Jan 26 16:28:23 DietPi transmission-daemon[6070]: [2022-01-26 16:28:23.791] [Anime Time] Attack on Titan S1 - S3+OVA [BD][Dual Audio][HEVC 10bit x265][AAC] IPv4 DHT announce failed (firewalled, 163 nodes): Success (tr-dht.c:737)
Jan 26 16:28:31 DietPi systemd[1]: transmission-daemon.service: Main process exited, code=killed, status=11/SEGV
Jan 26 16:28:31 DietPi systemd[1]: transmission-daemon.service: Failed with result 'signal'.

I restart the service and it works for some time and then runs into the same problem.
The main reason I got a pi was to use it with torrents but none of the clients seem to be working fine for me. Would greatly appreciate any help around this.


Edit : On my router, I’ve opened the port 8096 on the static IP of my raspberry pi to user Jellyfin remotely.

2

just a question because I see this inside the logs. Do you have a firewall somewhere on your network or locally on the system? Because the message is giving following message

IPv4 DHT announce failed (firewalled, 163 nodes)

Not sure if this is an issue of Transmission itself. At least there is an issue existing on Transmission GitHub https://github.com/transmission/transmission/issues/564

3

I do not remember setting up any firewall on my router. If anything, it would’ve been set up with the router itself. Is there any way I can check this ? Because these same torrents work perfectly on my windows and another mac device I use.

4

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.