Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#1305 closed Bug (fixed)

Transmission losing data - Session Transfer significantly higher than actual download

Reported by: Toby Owned by: charles
Priority: High Milestone: 1.40
Component: libtransmission Version: 1.30
Severity: Critical Keywords:
Cc:

Description

Ever since 1.30, Transmission has been losing a good portion of the data is has been downloading. This is evident when comparing the 'Session Transfer' figure to the amount that has actually been downloaded in a torrent.

For example, while downloading a 1000 MB file, Transmission says it's downloaded 1100 MB in the Session Transfer statistic (and looking at bandwidth usage and download speeds, it has indeed downloaded this much), but the actual download is only 20% complete. The amount of data lost varies, but a large number of users have experienced it and reported it:

http://forum.transmissionbt.com/viewtopic.php?f=2&t=5624

This bug is critical because:
1) downloads are taking significantly longer than they should;
2) the amount of extra bandwidth used and wasted is horrible for people with limited bandwidth (such as Australian Internet users.)

This bug has surprisingly made its way through 4 releases (1.30 - 1.34). The current workaround is to revert back to 1.22, or to use another torrent program.

Attachments (1)

transmissionr6954downlobe4.png (154.3 KB) - added by charles 12 years ago.
visual evidence of the fix

Download all attachments as: .zip

Change History (16)

comment:1 Changed 13 years ago by arpan

I have the same error. It shows 1GB downloaded. But the file is only a 175MB file, and it's only 40% complete. This is happening repeatedly.

comment:2 Changed 13 years ago by arpan

Note: This is on Leopard 10.5.5 with Transmission 1.34

comment:3 Changed 13 years ago by TVadim

You can look http://wl500g.info/showpost.php?p=109078&postcount=576graph of loading of the channel and record data to a disk. After start or a pause/resume real speed of downloading high, but falls after several minutes.
ASUS WL-500gP, Oleg firmware.

comment:4 Changed 13 years ago by charles

  • Component changed from Transmission to libtransmission
  • Milestone changed from None Set to 1.40
  • Owner set to charles
  • Status changed from new to assigned

comment:5 Changed 13 years ago by charles

This appears to only happen in a few cases, but in those cases it's pretty serious. This needs to get sorted out.

comment:6 Changed 13 years ago by malachi

You're lucky, charles. This bug happened to every torrent I had. The severity varies, but I've had a few download 400 MB and gain only 100 MB in the resulting data file.

comment:7 Changed 13 years ago by TVadim

IMHO the libtransmission requests the identical data from peers which then are rejected. Reduction max-peers-global to 10-15 allows to bypass this problem.

comment:8 Changed 13 years ago by charles

there's a possible fix for this in r6865. I'd appreciate people seeing this behavior to test this out and leave feedback.

comment:9 Changed 13 years ago by charles

  • Keywords backport-candidate added

comment:10 Changed 13 years ago by Toby

Testing with r6869, this issue does not seem to have been fixed, unfortunately. I've downloaded 51.6 MB of a 174.2 MB file, and my session transfer is up at 108.2 MB.

comment:11 Changed 13 years ago by charles

I agree that it's not fixed. I'm working on it now.

comment:12 Changed 13 years ago by charles

r6882 has another patch that may improve behavior. As with the previous one, user feedback here would be much appreciated.

comment:13 Changed 12 years ago by charles

  • Keywords backport-candidate removed
  • Resolution set to fixed
  • Status changed from assigned to closed
  • Version changed from 1.34 to 1.30

From the thread:

"Just downloaded the latest nightly build (6919). Tremendous improvement. The Have count actually reflects my transfer speed."

comment:14 Changed 12 years ago by charles

Reading over the code, I found a way to make it a little more efficient still. There's a new and improved fix in r6954.

Changed 12 years ago by charles

visual evidence of the fix

comment:15 Changed 12 years ago by charles

From the thread:

"1.40 hands down fixes the issue being discussed in this thread, better even than it was in 1.22 i think!"

Note: See TracTickets for help on using tickets.