Opened 10 years ago

Closed 10 years ago

#4135 closed Bug (worksforme)

When verification inexplicably fails, files are marked as have and downloads paused

Reported by: Waldorf Owned by: jordan
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.22
Severity: Normal Keywords:
Cc: mikael@…

Description

I want to report these findings before you release 2.30, since I do notice a lot of instabilities in the current svn builds.

What exactly happens is still unclear to me. Though:

  • I notice downloads paused at 99% with a failed piece(-s) warning
  • A verify (both svn & v2.22) return far less than what was previously indicated
  • I notice failed downloaded data (20% of torrents), something that was rare (unseen even) with v2.22 and earlier
  • Lot and lots of failed pieces errors in the log
  • Not limited to whole torrents. On selective-downloads, the selected files get marked as complete. (Quite annoying, since the .part gets removed and I only notice they are corrupt when I try to play them)

I notice this behavior more often on larger (4GiB+) and/or slower (<32kbs) torrents.

  • Slower torrents seem unable to finnish on their own, since they always get paused.

Although I noticed specific data loss (eg. downloaded: 500MiB+, verified: 350MiB, failed: 0KiB), I can't attribute this to 2.30 with certainty. It's likely caused by switching to 2.22, which (with the introduction of lazy verification) doesn't recognize any data and tries the download anew. Probably corrupting existing data.

(Maybe a 2.23 that does a verify of existing, though unverified, data would be in order for those switching back from 2.30?)

Change History (10)

comment:1 follow-up: Changed 10 years ago by jordan

If you're jumping back and forth between nightlies and 2.22 that's probably going to cause you some trouble. The .resume file parts which specify which pieces a torrent has changed slightly between those versions.

comment:2 in reply to: ↑ 1 Changed 10 years ago by Waldorf

Replying to jordan:
That's why I separated "Although I noticed specific data loss [...]" from the rest, since it's not only probably, but likely the cause for the data loss. Still it's, a symptom I noticed, and I felt obliged to at least mention it.

comment:3 Changed 10 years ago by jordan

Is this still an issue in more recent nightly builds?

comment:4 Changed 10 years ago by jordan

Is this still an issue in more recent nightly builds?

comment:5 Changed 10 years ago by mikal

I notice this as well. I am running 2.22 and have never tried svn. I was suspecting my btrfs file system, but I have ruled that out now. I have torrents that complain on broken pieces and some that stop on 99.8%.

comment:6 Changed 10 years ago by mikal

  • Cc mikael@… added

comment:7 follow-up: Changed 10 years ago by jordan

mikal, Is this still an issue in more recent nightly builds?

comment:8 in reply to: ↑ 7 Changed 10 years ago by mikal

Replying to jordan:

mikal, Is this still an issue in more recent nightly builds?

I haven't tried any recent builds, I am not that keen on trying a svn snapshot. I use my installation alot. I am even less keen if there can be data loss when switching back and forth.

But I'm keen on helping sort this out if you find it hard to reproduce.

comment:9 Changed 10 years ago by jordan

  • Version changed from 2.22+ to 2.22

Changing version based on mikal's information in comment:5

Waldorf, Is this still an issue in more recent nightly builds?

comment:10 Changed 10 years ago by jordan

  • Resolution set to worksforme
  • Status changed from new to closed

Okay. Well I've asked four times over six weeks and gotten no reply from anyone running a nightly, beta, or 2.3, so I'm closing this ticket as WorksForMe? for now.

If anyone has new information on this bug in the 2.3x series, please reopen this ticket after adding that new information. Thanks

Note: See TracTickets for help on using tickets.