Some functions aren't working like they should (see description)

Bug #568322 reported by Michal Dziczkowski
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
transmission (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: transmission

Some of discovered my me bugs.

I. Torrent properties

* changing download priorities don't work (files are downloaded independent from set priorities)
* after deselecting the "Download" checkbox and then selecting it again, the file don't start to download again
* setting an speed limit and/or torrent priority has no influence on the download
* seed until ratio has no influence on torrent
* there is no possibility to set more then maximum 3000 peers

II. Global

* there is no possibility to set more then maximum 3000 peers and 300 per torrent
* there is no possibility (getting an error) to add torrent with similar name then the one with was added
* the "ask for more peers" need to get improved because something nothing happens for long time
* setting limits (speed and/or peers) has no influence on download

ProblemType: Bug
Architecture: i386
Date: Thu Apr 22 11:52:07 2010
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/transmission
LiveMediaBuild: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
Package: transmission-gtk 1.75-0ubuntu2
ProcEnviron:
 LANG=pl_PL.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: transmission
Uname: Linux 2.6.31-14-generic i686

Revision history for this message
Michal Dziczkowski (mdziczkowski) wrote :
Revision history for this message
Darrell Henderson (mooserider2) wrote :

* there is no possibility to set more then maximum 3000 peers and 300 per torrent

This seems to be more of a function but i have found problems with almost everything you have described

Changed in transmission (Ubuntu):
status: New → Confirmed
Revision history for this message
Charles Kerr (charlesk) wrote :
Download full text (4.3 KiB)

Thank you for taking the time to report this bug and helping to make Ubuntu and Transmission better.

This is quite a shopping list of items. I'm going to give a brief response on each of them. Then I'm going to close this ticket simply because, from a logistical standpoint, it's a nightmare to manage a ticket with 10 different issues. Specific discussion about any of the 10 issues will make the ticket's comments impossibly cluttered, and let's say for the sake of argument all of them are valid... the ticket still couldn't be closed until the last item was checked off the list.

So if after reading my replies you still feel that one ore more of these issues are valid, please open separate tickets for them so that they can be addressed individually.

> 1. there is no possibility to set more then maximum 3000 peers
> 2. there is no possibility to set more then maximum 3000 peers and 300 per torrent

There is no reason to want 3000 peers. These two suggestions will not be used upstream. The only thing that many peers will do is flood your available bandwidth with the non-piece protocol messages to all those peers. It would also cause most routers to panic and run away.

> 3. seed until ratio has no influence on torrent

If by this you mean torrents continue to seed after the seed ratio has been reached, this is confirmed to happen sometimes. The upstream ticket is http://trac.transmissionbt.com/ticket/1869.

> 4. the "ask for more peers" need to get improved because something nothing happens for long time

You should look at the "Tracker" tab in the Torrent Properties dialog to see if the announces to your tracker are succeeding. If so, then "Ask for more peers" is working exactly as designed. If announces are going through but the tracker doesn't have any more peers, then asking the tracker for more isn't going to do any good. If the announces are /not/ going through to the tracker, then you are probably experiencing the announce logjam bug that is fixed in the latest available version of the package.

> 5. changing download priorities don't work (files are downloaded independent from set priorities)

There are many factors at work here, and priorities are only one of them. If a particular peer doesn't have the pieces we need for a file, we won't request them from that peer. Or, if we do request them from a peer that's responding slowly, pieces from a different file may come in faster. We can control which pieces we ask for, but we can't control which order we get them in.

> 6. after deselecting the "Download" checkbox and then selecting it again, the file don't start to download again

I'm not able to reproduce this issue. Could you please try this in Transmission 1.92 and see if the problem persists?

> 7. setting a per-torrent speed limit has no influence on the download

Setting a speed limit on the download will influence the maximum speed at which that torrent downloads. Bug #460733 discusses how the numbers Transmission reports can differ somewhat from what's actually happening -- Transmission doesn't count non-piece data such as protocol messages and tracker announces in its bandwidth caps, f...

Read more...

Changed in transmission (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Michal Dziczkowski (mdziczkowski) wrote :

This is an answer to Charles:

ad. 3

> If by this you mean torrents continue to seed after the seed ratio has been reached, this is confirmed to happen sometimes. The upstream ticket is http://trac.transmissionbt.com/ticket/1869.

in many cases yes

ad. 4

> If so, then "Ask for more peers" is working exactly as designed

by one torrent I had a list of trackers and the "ask for more peers" function was disabled and grayed out

ad. 5

> There are many factors at work here, and priorities are only one of them. If a particular peer doesn't have the pieces we need for a file, we won't request them from that peer. Or, if we do request them from a peer that's responding slowly, pieces from a different file may come in faster. We can control which pieces we ask for, but we can't control which order we get them in.

it's strange that you think so... Some other torrent clients (mostly windows ones) have the same possibility and after the priority got changed, the files with higher priority were downloaded in the first order (tested on the same file on other torrent client's)

ad. 6

> I'm not able to reproduce this issue. Could you please try this in Transmission 1.92 and see if the problem persists?

in this case please update the Ubuntu repository to have the newer version on. The Ubuntu repositories are mostly outdated

ad. 7

> If you want to say there is no influence at all then I'll need to see more information.

I have changed allowed speed to limit brandwitch usage for upload then some time the limit was exceeded and the upload was going faster

ad. 8

> Setting torrent priority influences which peers get a first shot at the bandwidth that Transmission has allocated for that timeslice. If the peers on a high-priority torrent are unable to make use of that extra bandwidth, then the normal- and then low- priority torrents are given an opportunity to use it. We can control which peers we try first, but we can't control how much they're willing to send us.

Not exactly true. I have 2 torrents and I had set 2 priorities: one was as hight and second as normal. The normal one was treaten by client like with higher priority then the hight one

ad. 9

> Same as my response for #7, though I'll add some users have gotten confused by accidentally turning off the "Honor Global Limits" checkbox in Torrent > Properties > Options s.t. a torrent will download faster than the user wanted it to.

I think that the "Honor global limits" is redundant in the client and makes only users confused and frustrated about beeing unable to set individual transfer speed's

ad. 10

> Setting the peer limit definitely does influence the maximum number of peers that you're allowed to have. Could you please try this in Transmission 1.92 and see if the problem persists?

The answer is the same as in point 6

Changed in transmission (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Please don't reopen this bug. Report a single issue per bug, else it's almost impossible to do anything with

Changed in transmission (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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