Bug 308579

I can confirm the exact behavior you described, both with 4.2 and 4.3 branches.
Moreover, say you queued x torrents using only magnet links. If after that you 
queue another torrent, but this time you use a .torrent file, then the relative order 
of the x old torrents in the queue will be completely changed in a seemingly random 
way.

I'm using debian unstable.

(In reply to comment #1)
> I can confirm the exact behavior you described, both with 4.2 and 4.3
> branches.
> Moreover, say you queued x torrents using only magnet links. If after that
> you 
> queue another torrent, but this time you use a .torrent file, then the
> relative order 
> of the x old torrents in the queue will be completely changed in a seemingly
> random 
> way.
> 
> I'm using debian unstable.

The same thing happened to me today only with .torrent files. Two downloads remaining on top of the queue have been moved to the bottom when adding a third torrent (the queue is relatively long, 100 items).

Seems the code appending torrents to the queue is broken in some way.

I started to look at the code but it seems to do the right thing when a torrent is added:

queuemanager.cpp:654 in function torrentAdded
foreach (TorrentInterface * otc,downloads) {                                         
  int p = otc->getPriority();       
  otc->setPriority(p+1);            
}                                         
tc->setAllowedToStart(start_torrent);     
tc->setPriority(0);                       
rearrangeQueue();

which sets priority of the added torrent to 0 and increment by 1 other torrents priority.

I don't know yet what's going on. I unsuccessfully tried to inverse the priorities to see if I could get the added torrent to go to the end of the queue but all I was getting is a ktorrent without ability to start torrents.

I'll take a deeper look but i'll appreciate any help from regular devellopers about how the queue is working and tips about debugging ktorrent as it is the first time I take a look at the source code.

From what I can see from the code snippet you posted, this priority queue seems to be quite problematic...
First of all, each insertion costs O(n), where n is the number of torrents in the queue. Sure, the torrents in the queue will probably never be more than  a couple of hundreds (I'm also counting the ones that have been finished, which seem to remain in the queue) but one can simply implement the priority queue with some O(log n) tree-based dictionary from the base c++ libraries at zero cost and be done with it.

Second, what's the meaning of the integer storing the priority?I can't tell from the code snippet if a larger integer means a higher priority or vice-versa. Because if we are in the second case the FIFO order is not respected (the new torrent gets priority 0 and jumps in front of all the other ones). On the other hand, if we are in the first case that would explain why the "visual" queue shown in client window doesn't match the actual download order: the visual queue sorts torrents by increasing priority number while the actual downloading order is the opposite, i.e. in decreasing order by priority number (torrents with larger numbers first).
And maybe these conflicting sorting orders are the cause of the other misbehaviour, when one change a torrent priority by moving it down in the visual queue and the actual downloading order is suddenly reversed.

I'm just guessing from the code you posted.

I have the same problem.
It seems new torrent is placed to the end of "real queue", but GUI of queue (Queue Manager) shows the situation incorrectly (in inverted order). And this "real queue" works correctly until it receive signal from Queue Manager (when rearranging torrents in it).

Git commit a80d92a76f41c5e70291561ef7382aa253e1be0b by Joris Guisson.
Committed on 22/12/2012 at 13:24.
Pushed by guisson into branch 'master'.

Fix queue order not reflecting reality in some circumstances

M  +1    -0    ChangeLog
M  +23   -24   ktorrent/tools/queuemanagermodel.cpp
M  +1    -0    ktorrent/tools/queuemanagermodel.h

http://commits.kde.org/ktorrent/a80d92a76f41c5e70291561ef7382aa253e1be0b

I'm sorry but it doesn't seems to be completely fixed in 4.3.1.
I didn't yet try all the cases but at least in the following it still seems to behave in the wrong way:

say your queue only allow one active torrent at a time.

1) add a torrent via magnet link -> it goes on pos 1 in the queue and it starts
2) then add a torrent via torrent file -> it goes on pos 1 in the queue but it doesn't replace the 
    previous one as the active torrent 

So, if the meaing of the "pos" field in the queue is the usual one (i.e. the torrent that occupies it is the one active) then
a) either ktorrent puts the second torrent in pos 1 and then it starts it (it would not be a queue but anyways)
b) or ktorrent puts the second torrenti in pos 2 and doesn't start it (the correct semantic for a queue)

Neither one of these is happening.

Now I'm starting to think that the fix that  Joris Guisson pushed didn't make it into 4.3.1 because the queue is behaving exactly as before.
A more complete case:

1) you add, say, 5 torrents to the queue, each one via magnet link (the same would happen with torrent files I think)
2) they end up in reverse order in the queue: i.e. the one that was queued as first is in pos 5, the one that was queued as second is in position 4 ecc
3) if the queue remains untouched the downloads would proceed as follows: the torrent in pos 5 is downloaded first, then the one in pos 4 ecc. So up until now the only problem would be that
the queue does not respect the usual meaining for "position number one, number two" ecc 
4) however, if you start moving torrents in the queue (using the arrows in the GUI) things get messy again. For example, let's say that you swap the torrents in position 3 and 2 while the one in pos 5 is still active (and the only downloading). If the problem with the queue was just that positions are inverted wrt the usual meaning, then after the swap we would just have the torrents in pos 3 and 2 swapped and the one in pos 5 would still be the active one. Instead, what does happen is that the torrents in pos 3 and 2 are indeed swapped but the torrent in pos 1 (the last one added) suddenly becomes the active one.

Now I'm starting to think that the fix that  Joris Guisson pushed didn't make it into 4.3.1 because the queue is behaving exactly as before.
A more complete case:

1) you add, say, 5 torrents to the queue, each one via magnet link (the same would happen with torrent files I think)
2) they end up in reverse order in the queue: i.e. the one that was queued as first is in pos 5, the one that was queued as second is in position 4 ecc
3) if the queue remains untouched the downloads would proceed as follows: the torrent in pos 5 is downloaded first, then the one in pos 4 ecc. So up until now the only problem would be that
the queue does not respect the usual meaining for "position number one, number two" ecc 
4) however, if you start moving torrents in the queue (using the arrows in the GUI) things get messy again. For example, let's say that you swap the torrents in position 3 and 2 while the one in pos 5 is still active (and the only downloading). If the problem with the queue was just that positions are inverted wrt the usual meaning, then after the swap we would just have the torrents in pos 3 and 2 swapped and the one in pos 5 would still be the active one. Instead, what does happen is that the torrents in pos 3 and 2 are indeed swapped but the torrent in pos 1 (the last one added) suddenly becomes the active one.

The commit only happened on the master branch, so the fix is not part of 4.3.1