transmission consistently reports having downloading 115-130% of the required data with no corresponding corrupt download data numbers
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Transmission |
Fix Released
|
Unknown
|
|||
transmission (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: transmission
After the update to the 1.80 branch of Transmission I am seeing an issue where every torrent will report having downloaded a larger amount of data than the torrents content account for without a corrupt data count to make up for the difference.
As this happens consistently with every torrent I am suspecting a bug is in play.
E.g. [redacted] gives the following numbers when fully downloaded:
Downloaded: 1.8gb
Has: 1.5gb
No additional download due to corruption in this case.
or roughly 130%. Now since share ratio is set for 1,00 this means that you'll upload far more data than you download. Good for the swarm but bad if you are on a limited connection or pay for the data.
As a workaround one can set the share ratio at less than 1.00 to match the additional download.
In the given example I used the magnet link download but I've seen the same issue using regular .torrent files.
ProblemType: Bug
Architecture: amd64
Date: Wed Dec 23 21:42:25 2009
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
NonfreeKernelMo
Package: transmission (not installed)
ProcEnviron:
LANG=da_DK.UTF-8
SHELL=/bin/bash
ProcVersionSign
SourcePackage: transmission
Tags: lucid
Uname: Linux 2.6.32-9-generic x86_64
summary: |
transmission consistently reports having downloading 115-130% of the - required data with no corresponding corrupt dowload data numbers + required data with no corresponding corrupt download data numbers |
tags: | added: regression-potential |
Changed in transmission: | |
status: | Unknown → Fix Released |
This is a regression that was introduced by ticket #2548 which, ironically, attempted to *reduce* the number of redundant requests. The rewritten piece requester has a more efficient design, but a bug in its implementation caused this overage.
Upstream ticket #2548 was reopened in http:// trac.transmissi onbt.com/ ticket/ 2548#comment: 4 to address this regression. The upstream ticket has been re-closed because this issue has been fixed: http:// trac.transmissi onbt.com/ ticket/ 2548#comment: 6