#1103416 Transmission 4.1 beta shredding local data

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:
#1103416#5
Date:
2025-04-17 09:58:26 UTC
From:
To:
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

#1103416#10
Date:
2025-04-17 11:53:45 UTC
From:
To:
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

#1103416#17
Date:
2025-09-10 16:41:22 UTC
From:
To:
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

#1103416#22
Date:
2025-09-10 20:13:20 UTC
From:
To:
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

#1103416#27
Date:
2025-09-11 05:20:28 UTC
From:
To:
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

#1103416#32
Date:
2026-07-21 07:42:26 UTC
From:
To:
Hi,

Could this be related to https://github.com/transmission/transmission/issues/9000 ?

Alex

#1103416#37
Date:
2026-07-21 08:16:40 UTC
From:
To:
Note: Since I started using transmission 4.1.3 from trixie-backports,
the problems disappeared.

Regards

#1103416#42
Date:
2026-07-21 08:38:02 UTC
From:
To:
Hi,

pause/resume happens happen at app restart.

Okay marking as fixed in this version.

Thanks,

Alex