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

[David Nielsen]

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)
ProcEnviron:
 LANG=da_DK.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-9.13-generic
SourcePackage: transmission
Tags: lucid
Uname: Linux 2.6.32-9-generic x86_64

[Charles Kerr (charlesk)]

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.transmissionbt.com/ticket/2548#comment:4 to address this regression. The upstream ticket has been re-closed because this issue has been fixed: http://trac.transmissionbt.com/ticket/2548#comment:6

[Charles Kerr (charlesk)]

(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.)

[David Nielsen (davidnielsen-deactivatedaccount)]

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

[Charles Kerr (charlesk)]

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.

[Launchpad Janitor (janitor)]

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 configure.ac 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