Opened 10 years ago

Closed 8 years ago

Last modified 8 years ago

#4540 closed Bug (duplicate)

Torrent queues order not preserved

Reported by: leandroong Owned by: jordan
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.71
Severity: Normal Keywords:
Cc: 1100101@…, hgabreu@…, saverio.pub2@…, noone3@…

Description

Stopping all torrents and resuming all does not follow pre-ordered queueing set. I would expect at least FIFO order or saved user queue order listing.

Attachments (1)

rpc-use-queue-order.diff (842 bytes) - added by dbosst 8 years ago.
make rpc use queue order when starting torrents

Download all attachments as: .zip

Change History (36)

comment:1 Changed 10 years ago by jordan

  • Component changed from Web Client to libtransmission
  • Owner set to jordan
  • Version changed from 2.33+ to 2.40

comment:2 Changed 10 years ago by KyleK

  • Cc 1100101@… added

comment:3 Changed 9 years ago by hgabreu

  • Cc hgabreu@… added

comment:4 Changed 9 years ago by livings124

Is this still an issue in 2.5? I haven't been able to reproduce this.

comment:5 Changed 9 years ago by leandroong

Nope. No error actually. Just realized that I need to set order to "queueing order" to see the real order. Consider it closed.

comment:6 Changed 9 years ago by livings124

  • Resolution set to invalid
  • Status changed from new to closed

comment:7 Changed 9 years ago by hgabreu

Yes, this is still an issue in 2.5 Steps to reproduce: 1- click on "View" > "Sort by Queue" 2- right click on any torrent that is lower on the list and pick "Queue" > "Move to top" memorize (or write down) you torrents queue order 3- close transmission 4- open it again verify that the torrent that you moved to the top is not there anymore.

Also, but not exactly this issue, when transmission is restarted, torrents that were in queued state just start "stopped".

comment:8 Changed 9 years ago by livings124

What client is this in? This doesn't occur in the Mac client.

comment:9 Changed 9 years ago by KyleK

This problem exists with transmission-daemon. I don't know about the gtk or the Qt version.

comment:10 Changed 9 years ago by KyleK

  • Resolution invalid deleted
  • Status changed from closed to reopened

comment:11 Changed 9 years ago by leandroong

Retested procedures: 1.) add 3 torrent to download; 2.) set sort order by queue; 3.) play around, make the top torrent go bottom, go top, and close transmission web GUI. All behaves in order.

Only thing here, if sort order is not set to queue order, menu for move top, up, down, bottom should be available as an option. This is what causes the complain by others, I think.

comment:12 follow-up: Changed 9 years ago by livings124

  • Component changed from libtransmission to Daemon

comment:13 Changed 9 years ago by leandroong

sorry, "should not be available" instead of "should be..."

comment:14 Changed 9 years ago by hgabreu

I'm using transmission-gtk 2.5 on linux (where the problem still exists).

comment:15 in reply to: ↑ 12 Changed 9 years ago by rb07

  • Component changed from Daemon to libtransmission

Replying to livings124: The problem is in libtransmission, all programs that use it (daemon, GTK+, and Qt -- probably CLI) get their queue turned into paused torrents after restart.

Preserving the order is not even in the picture, the queue is just lost.

comment:16 Changed 9 years ago by livings124

Ah, my misunderstanding. The Mac client doesn't lose its order, but it also keeps a separate transfer list, while the other clients load directly through lib libtransmission's config functionality.

comment:17 Changed 9 years ago by rb07

My mistake, the original poster is a MAC user, so he was talking about the Mac application, and later reverted his comment saying its not a bug at all. By this the ticket should be closed as invalid.

What I was thinking is a similar ticket: #4484, which describes the problem with the daemon, and only lacks the part about libtransmission and how all the other clients are affected.

comment:18 Changed 9 years ago by livings124

I'm confused. Is #4484 the same thing? Is the issue of this ticket valid and different?

comment:19 Changed 9 years ago by rb07

They are similar, but not the same.

The similarity confused several of us, but looking that leandroong opened this ticket, and then reverted his report on comment:5, and that he is using the Mac application (which doesn't have the problem), makes the ticket invalid and different.

Everybody else, including me, was thinking of the problem reported in #4484, which is a libtransmission problem.

Last edited 9 years ago by rb07 (previous) (diff)

comment:20 Changed 9 years ago by livings124

  • Resolution set to worksforme
  • Status changed from reopened to closed

Alright, then I'll resolve this in favor of #4484. If I'm misinterpreting you're response, please update.

comment:21 Changed 9 years ago by sabine332

  • Cc saverio.pub2@… added
  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Type changed from Enhancement to Bug
  • Version changed from 2.40 to 2.71

comment:22 Changed 9 years ago by sabine332

I still get the problem, and it's not #4484.

I'm on Precise 64bit, with Transmission GTK 2.71.

Every time transmission is restarted, the queue order is lost. This is very annoying, because having a queue order is needed in my case.

comment:23 Changed 8 years ago by mleczan

Issue is still there, after setting own queue order and then restart transmission queue is not preserved.

comment:24 Changed 8 years ago by BorderBoetie

I'm also seeing this on 2.77 on Ubuntu 13.04, 12.10 and 12.04.

comment:25 Changed 8 years ago by leandroong

Torrent queueing order basis cannot use torrent_id, it changes everytime transmission get restarted. Torrent file date is fixed and should be used as my suggestion.

comment:26 Changed 8 years ago by dskchk

  • Cc noone3@… added

comment:27 Changed 8 years ago by delcaran

  • Version changed from 2.71 to 2.81

This is still an issue in transmission-daemon 2.81. This is what I've done:

  • Stated some torrents in state "downloading", "in queue (not downloading due to download queue size", "seeding" and "finished".
  • Messed up with queue_position and written it down
  • Closed daemon with transmission-remote --exit
  • Started daemon
  • Situation:
    • All queue_positions are randomized, not the order I choose.
    • Torrents that were "in queue" are now paused.
    • All other torrents are in the same state as before closing (except for queue_position and torrent_id)

This is a really annoying issue, mostly because it's simply avoidable using torrent_hash and some configuration file... Now I'm using some python scripts to solve this issue (along with other customizations), but a fix would be very appreciated.

comment:28 Changed 8 years ago by livings124

  • Version changed from 2.81 to 2.71

comment:29 Changed 8 years ago by livings124

  • Resolution set to duplicate
  • Status changed from reopened to closed

Closing as duplicate to #5298

comment:30 Changed 8 years ago by hgabreu

Why close this as duplicate of a newer ticket that is less broad than this one? #5298 is only about OSX, I have this issue on Linux.

comment:31 Changed 8 years ago by livings124

#5298 has a suggested solution.

comment:32 Changed 8 years ago by gabrielrcp

I don't fix this is a duplicate of #5298. My fix there does not fix this issue (at least not the one in the original message, I got confused reading the comments).

I believe this problem comes from the rpc implementation.

The method torrentStart from libtransmission/rpcimpl.c just gets the list of torrent's to start in whatever order is returned by the method getTorrents and calls tr_torrentStart in that order. I believe a more sane behavior (that would close this issue) is to sort the torrents by queue_position when no id's are found in args_in. This probably should be done by getTorrents, but I don't understand this code well enough to do this modification.

I run transmission as a daemon and control it using a third party app that uses the RPC, so I don't know if a similar issue occurs in the gtk/qt/mac clients.

Changed 8 years ago by dbosst

make rpc use queue order when starting torrents

comment:33 Changed 8 years ago by dbosst

Regarding gabrielrcp's previous post, I have implemented queue sorting in the rpc code by modifying torrentStart in libtransmission/rpcimpl.c (see attachment).

A few simple tests show it is working fine.

comment:34 Changed 8 years ago by cfpp2p

... I have implemented queue sorting in the rpc code by modifying torrentStart in libtransmission/rpcimpl.c (see attachment).

Thanks dbosst, patch works good!

comment:35 Changed 8 years ago by jordan

I've added this patch in r14209. Thanks dbosst!

Note: See TracTickets for help on using tickets.