Downloaded data not saved

[ThinkChaos]

What is the issue?

Hi,

I ran into an issue where a torrent was downloading data but it wasn't being saved, or at least not being counted as progress. Basically I was seeing bandwidth being used, but the reported progress was stuck. Pausing it and resuming it didn't resolve the issue.

At the same time I had a torrent that failed because the destination folder was not writable (/var/empty). When I moved that torrent, the first one got unstuck... I have no clue if it was just lucky timing or actually linked, but mentioning just in case.

I tried to reproduce the issue with the following scenario to no avail:

• add and start a torrent that makes progress normally
• add a second torrent as paused, set its destination to /var/empty and start it. It will error as soon as it tries to save a block to disk

Any destination folder where transmission cannot write should do, /var/empty is just a handy existing one.

(If you're curious about why I use /var/empty: I set my defaults to that destination + paused, and have an "on-add" script to detected torrent contents, and set the path + resume if it does)

Which application of Transmission?

transmission-daemon on Linux

Which version of Transmission?

4.0.5

[fresh-water]

no data downloading into torrent file(s) but the Transmission Status Bar on top shows KB/s and M/s data downloading. i can see KB/s M/s in status bar downloading for hours but not one byte is saved into the individual torrent line stats. issue does not resolve itself. Transmission ran for 6 hours multiple torrents, nothing. this had happened 3 times, i must quit then launch Transmission. i updated nothing recently (weeks). Transmission updated to 4.0.5 months ago. use Transmission all day every day.
4.0.5 , M1 14.4.1

[ThinkChaos]

Here's one I left running for a bit:

[ExceptionalError]

Maybe the same as #5747

[ThinkChaos]

Seems quite similar indeed.
And I can confirm as shown in the screenshot above no corruption is going on, or at least that cause the hashfail stat to increase.

[fresh-water]

i didn't leave a screenshot in case there was an IP or something i didn't notice. another issue is my Transmission no longer obeys BANDWIDTH>Global bandwidth limits>Download rate: i can set it to zero yet status bar displays MB/s being downloaded. months ago option used to work, i used it for years fine until recently.

[iccfish]

I think this was duplicate of #5797

[Carmageddon]

I think the same issue is happening to me.
I have Transmission running inside a docker container in my NAS, and recently resolved some long going permission issues that were causing write issues.
But now I see the same issue, here is screenshot for one example file.

You can see that it downloads 3 times more than the file size..

The progress in the file is stuck like this:
36.63 GB of 49.88 GB (73.4%) - remaining time unknown

The only way to update it, is periodically ask to verify local data - then it updates and if I am lucky, completes the torrent.

My docker-compose file (censored):

version: '3.3'
services:
  torrents:
    image: linuxserver/transmission:latest
    container_name: torrents
    environment:
      - PUID=1000
      - PGID=100
      - TZ=America/Halifax
      - USER=admin
      - PASS=somePass
    volumes:
      - /srv/dev-disk-by-label-NAS/Media/Russian:/russian
      - /srv/dev-disk-by-label-NAS/Media/Indexers:/watch
      - /srv/dev-disk-by-label-NAS/Media/Movies:/movies
      - /srv/dev-disk-by-label-NAS/Media/TV:/tv
      - /srv/dev-disk-by-label-NAS/Media/Kids:/kids
      - /srv/dev-disk-by-label-NAS/Media/config/transmission:/config
      - /srv/dev-disk-by-label-NAS/Media/Torrents:/downloads
    ports:
      - "51413:51413/tcp"
      - "51413:51413/udp"
      - "9091:9091/tcp"
    restart: unless-stopped
    network_mode: bridge

This verify trick bypasses the problem easily on small files like 1-3gb, but large 30-50gb, its too long to re-verify in order to "save" the progress..

How can I help diagnose it further? or what other things can I try? what other information needed?

[avogadro23]

Same issue here, which I've experienced all from 4.0 to 4.05, with Big Sur, Monterey, Ventura, and Sonoma.
A major issue, in my opinion.