- Package:
- transmission-gtk
- Source:
- transmission-gtk
- Description:
- lightweight BitTorrent client (GTK+ interface)
- Submitter:
- Stephan Verbücheln
- Date:
- 2026-07-21 08:41:03 UTC
- Severity:
- normal
- Tags:
For a few weeks, I was seeding some rare torrents with Transmission 4.0. After the update to 4.1 beta, Transmission started to “verify local data”, discarded the torrent data and started downloading from scratch. * I am using Transmission GTK in Gnome. * At the time, I was seeding five torrents with multiple files, totalling around 200 GB. * The filesystem is ext4 (within LUKS on SSD). * The location is ~/Downloads/Torrents/, which was configured to be the default location in Transmission. Unfortunately, I have not identified the root cause and I cannot provide examples for privacy reasons. I filed this bug anyway to raise awareness and block migration to Trixie. Regards Stephan
Hi, Sorry to hear that. I've been using 4.1.0~beta2 for 3 months and it has worked well for me. I have one 8 Gib torrent which transmission insisted on downloading most parts again arguing invalid data, but this was not automatic and I had to ask to "Verify local data" before any data shredding happeneded. Other torrents, from 3 Gib to 163 Gib, have been downloaded with earlier versions and have been well since. Could you provide an anonymized log have what happeneded? I cannot find any issue referring to something similar upstream, but probably beta versions do not get much testing. Will raise severity if I get another report on this, but without logs, it is difficult to have a hint about what might have happened for you. Thanks, Alex
Now I have used it for many weeks, including with stable Debian 13 Trixie. The problem persists. Often it downloads a large file (10 GB and larger) without detecting any error. But after manually asking Transmission to “verify local data” on completed torrents, it detects that one or two percent of the pieces are broken and starts re-downloading the missing pieces. In videos, it often goes unnoticed but then it shows artifacts. That's how it got to my attention. Regards Stephan
Hi, Can you spot a pattern: big files? big torrents? Or is this random? Can you reproduce with 4.0.6? What filesystem do you use? Is your hardware healthy? Can you test downloading a Debian iso and reproduce? Thanks, Alex
I am trying to investigate. I have no clue of the reason so far why it happens sometimes. I only used 4.0.x for a short time, but I never observed any bugs. Same for 3.x, which I used intensively for many years. Ext4. One one secondary machine this also happened on Btrfs. I am transferring terabytes of data regularly with various tools including rsync and sftp and I never had problems there. I also never had problems with Bookworm (Transmission 3.x) on the same machine. I had the same effect on another machine with Trixie, while an old machine with Bookworm was just fine. I already started trials like that. I will come back when I have more reliable steps to reproduce. The main use of my report so far is to find people who other people who are experiencing similar behavior. I could not find any fitting upstream bug either. Regards
Hi, Could this be related to https://github.com/transmission/transmission/issues/9000 ? Alex
Note: Since I started using transmission 4.1.3 from trixie-backports, the problems disappeared. Regards
Hi, pause/resume happens happen at app restart. Okay marking as fixed in this version. Thanks, Alex