multiple download works strangely

This is probably the highest priority bug fixed between 1.34 and 1.40, at least to my mind. It doesn't hit very many people, but if you're one of the lucky few, it's very annoying.

Great, thanks! :)

Fix included upstream with 1.40

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

---------------
transmission (1.40-0ubuntu1) jaunty; urgency=low

  * New upstream release (LP: #302672)
    - Tracker communication uses fewer resources
    - More accurate bandwidth limits
    - Reduce disk fragmentation by preallocating files (LP: #287726)
    - Stability, security and performance improvements to the RPC /
      Web UI server (closes LP: #290423)
    - Support compression when serving Web UI and RPC responses
    - Simplify the RPC whitelist
    - Fix bug that prevented handshakes with encrypted BitComet peers
    - Fix 1.3x bug that could re-download some data unnecessarily
      (LP: #295040)
    - Option to automatically update the blocklist weekly
    - Added off-hour bandwidth scheduling
    - Simplify file/priority selection in the details dialog
    - Fix a couple of crashes
    - New / updated translations
    - Don't inhibit hibernation by default (LP: #292929)
    - Use "close" animation when sending to notification area (LP: #130811)
    - Fix resize problems (LP: #269872)
    - Support "--version" option when launching from command line
      (LP: #292011)
    - Correctly parse announce URLs that have leading or trailing
      spaces (LP: #262411)
    - Display an error when "Open Torrent" fails (LP: #281463)
  * Dropped 10_fix_crasher_from_upstream.dpatch: Fix is in this
    upstream release.
  * debian/control: Don't just build-depend on libcurl-dev, which is
    a virtual package.

 -- Chris Coulson <email address hidden> Fri, 28 Nov 2008 15:33:48 +0000

charles - Do you think it is possible to isolate the patch that fixed this bug in 1.40? It would be great to be able to backport the patch to the Intrepid 1.34 version of Transmission, so I can nominate it for a SRU.

I'm not sure that it's a good candidate for backporting. I'd love to see this fixed in Hardy but it's a pretty involved patch.

Since 1.34 has the bug that makes Transmission completely unusable and forces users to switch to other programs, personally I think it doesn't matter for end user how you are going to fix the bug - backport it or make 1.40 available for all ubuntu releases where the bug occurs (assume Hardy and Intrepid). In any case we shouldn't wait until Jaunty released.

I'll look into it, but the reason I haven't done so already is because the backport will most likely be too much for Ubuntu's "changes should be as small as possible" rule of thumb.

Thanks charles. I've subscribed ubuntu-sru to get their thoughts on what would be acceptable for SRU.

Backporting the fix is of course acceptable.

Okay, reporting back on my findings... the backport is possible, but largish. If something
of this size is going to be accepted into Hardy, I suggest going a little further and doing
a 1.35 release specifically for Hardy, including this fix and a handful of other small but
worthy fixes. Looking over the logs, I've come up with these candidates for such a
release: http://www.pastebin.ca/1276568. That pastebin lists the bugs and URLS to
their Transmission bug tickets, which in turn have links to their diffs.

If this sounds like a good idea to the Hardy maintainers, let me know and I'll start work on it.

I am not ~ubuntu-sru so I can't speak on their behalf, but I think a 1.35 bugfix release for -updates would be nice; the issues in your pastebin sound like good candidates for a point release. However, make sure you coordinate with Martin / -sru to make sure you're on the same page whether you're submitting patches for each of those problems, or rolling a new version of a release. If doing the latter, make sure that ~ubuntu-sru is going to accept it before putting so much work into it.

On a tangential note I'm interested in backporting a recent version of Transmission to Intrepid if it contains worthwhile new functionality, too. This is not related at all to fixing the above bug(s) in -updates, of course.

Since Martin's CC'ed to this ticket, I'll wait for him to comment.

Charles,

doing a new upstream microrelease with important cherrypicks sounds excellent in general, and might also benefit other people/distros that way. In general I'm not so much concerned whether something is called 1.34+patches or 1.35, but rather whether the changes have a considerable potential to cause regressions. In general, 10 known bugs are better than introducing one new one. OTOH, with hardy being an LTS, backporting safe patches is a real benefit for users, and thus will be widely appreciated.

So we should make sure to have a good QA cycle on that, but otherwise I'm fine with this.

Thank you!

I'm slightly confused here. Does this bug only affect 1.3x releases of transmission? If that is the case, then the SRU needs to be targetted at Intrepid (which has 1.34), instead of Hardy. Hardy is still on 1.06, and I'm not sure if 1.06 is affected by this bug.

I don't know, Charles mentioned both hardy and intrepid.

I misspoke. This bug only affects [1.30...1.34], so Chris is correct about the SRU target.

Thanks for clarifying

Okay, I've done the backports. Most of the items in the list are one-liners
that I consider safe, but the primary reason for this work -- backporting the
overdownloading bug -- is (as predicted) a monster 1400 line diff. Who knows
how much QA is needed for that, especially since most of our active testers
have already moved onto 1.41 beta 2. I am very uncomfortable with this and
think that ~ubuntu-sru should be uncomfortable with it too.

As I said above, the overdownloading bug does not actually hit many users.
Sergiy Zuban overstates the case when he says it's "completely unusable".

===

Here are the safe, small low-hanging fruit 1.3x backports that I *do* endorse.
Should I make a separate ticket for this?

http://trac.transmissionbt.com/changeset/7276
http://trac.transmissionbt.com/changeset/7277
http://trac.transmissionbt.com/changeset/7278
http://trac.transmissionbt.com/changeset/7279
http://trac.transmissionbt.com/changeset/7280
http://trac.transmissionbt.com/changeset/7281
http://trac.transmissionbt.com/changeset/7282
http://trac.transmissionbt.com/changeset/7284
http://trac.transmissionbt.com/changeset/7285
http://trac.transmissionbt.com/changeset/7286

Thanks charles, 1400 lines is pretty big. I have to admit, I didn't agree with the comment about the current version being completely unusable either - I wasn't even aware of the bug until I came across this report, and I've been using transmission quite happily in Intrepid.

Based on your assessment of the impact of the bug, I'll downgrade the importance for the Intrepid task

I've created a new ticket <https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/305653> for those other changesets.

In my case 80-90% downloaded data was lost. For those who have bandwidth less then 1Mbit/s difference is very noticeable - download a movie for just several hours or several days. For me it's the same as "unusable".

As temporary solution I've installed 1.40 from unofficial repo
http://forum.transmissionbt.com/viewtopic.php?f=13&t=5604

Thanks, charles, for these investigations. I agree, if you have to backport half of 1.40 to fix this, then it's more appropriate to request a backport of 1.40 to intrepid and thus allow people to use that.

Thanks for opening the other bug, I'll mangle it accordingly.