#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)
Change History (16)
comment:1 Changed 14 years ago by arpan
comment:2 Changed 14 years ago by arpan
Note: This is on Leopard 10.5.5 with Transmission 1.34
comment:3 Changed 14 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 14 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 14 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 14 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 14 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 14 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 14 years ago by charles
- Keywords backport-candidate added
comment:10 Changed 14 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 14 years ago by charles
I agree that it's not fixed. I'm working on it now.
comment:12 Changed 14 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 14 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 14 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.
comment:15 Changed 14 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!"
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.