transmission consistently reports having downloading 115-130% of the required data with no corresponding corrupt download data numbers

Bug #499964 reported by David Nielsen on 2009-12-23
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
transmission (Ubuntu)
Nominated for Lucid by David Nielsen

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)
NonfreeKernelModules: nvidia
Package: transmission (not installed)
ProcVersionSignature: Ubuntu 2.6.32-9.13-generic
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
Charles Kerr (charlesk) wrote :

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 to address this regression. The upstream ticket has been re-closed because this issue has been fixed:

Charles Kerr (charlesk) wrote :

(This is "Fix Committed" in "Transmission". If I'm reading the Ubuntu guidelines correctly, though, that status doesn't qualify for "transmission (ubuntu)" until 1.80 beta 4 is released.)

Changed in transmission (Ubuntu):
status: New → In Progress
Changed in transmission:
status: Unknown → Fix Released

We should now have beta 5 in Lucid, however even with that release I seem to be experiencing this bug.

Charles Kerr (charlesk) wrote :

This seems to be fixed in 1.83. Downloading (and then deleting) the torrent referred to by the OP, Transmission 1.83 downloaded 1586907119 byes in order to get a 1584818137 byte torrent, which is 1.0013%, not the 115-130% reported in this ticket's summary.

description: updated
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package transmission - 1.83-0ubuntu1

transmission (1.83-0ubuntu1) lucid; urgency=low

  [ Krzysztof Klimonda ]
  * New upstream release (LP: #512391)
  * Fixes bugs:
    - transmission consistently reports having downloading 115-130% of the
      required data with no corresponding corrupt download data numbers
      (LP: #499964)
  * debian/patches/99_autoreconf.patch:
    - Refreshed for the new changes

  [ Chris Coulson ]
  * debian/patches/01_lpi.patch:
    - Updated to use a pkg-config check at configure time, and not hard
      code the library name in transmission_LDADD
  * debian/patches/dont_build_libevent.patch:
    - Updated to patch rather than configure. This stops
      it from breaking with an autoconf run (LP: #510776)
 -- Krzysztof Klimonda <email address hidden> Thu, 21 Jan 2010 18:23:05 +0000

Changed in transmission (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.