Opened 7 years ago

Last modified 4 years ago

#4617 new Bug

Transmission doesn't queue just finished downloads

Reported by: iro Owned by: jordan
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.84+
Severity: Normal Keywords:
Cc:

Description

I've set up transmission to queue seeding torrents.

When I download a new torrent and such torrent completes the download, Transmission leaves the torrent active instead of marking it "Queued for seeding" and respecting the queue order.

Change History (11)

comment:1 Changed 7 years ago by livings124

  • Component changed from GTK+ Client to libtransmission

I can confirm this behavior on the Mac client.

comment:2 Changed 6 years ago by Ensoniq

My apologies to the devs for opening the duplicate #4951 ... I had not seen this. Hopefully this old bug will get a new solution. :)

comment:3 follow-up: Changed 5 years ago by jordan

livings124, is this still an issue in 2.7x?

comment:4 in reply to: ↑ 3 Changed 5 years ago by Ensoniq

Replying to jordan:

livings124, is this still an issue in 2.7x?

Jordan -

I can confirm on the Mac, version 2.76 (13785), that this issue still exists.

Just to re-clarify the behavior:

Preferences set to:

  • Download with maximum of 1 active transfers
  • Seeding with maximum of 1 active transfers

Start 2 simultaneous torrents.

First download begins, finishes, continues to seed. Second download begins, finishes, continues to seed.

Manually pause the second torrent, then resume. Status correctly changes to "Waiting to seed..."

The logic for Pause & Resume honors the seeding preference. It just won't kick in automatically after a download completes.

Thanks!

comment:5 Changed 5 years ago by dcorban

I also added a duplicate report, sorry. This is happening to me on my Mac and it is driving me crazy. I end up with a dozen torrents seeding, but none of them getting a decent portion of my upstream.

This was reported in 2.42 and still exists in the current version (2.80).

comment:6 Changed 4 years ago by zwastik

I am using transmission-daemon 2.82 (14160) (archlinux) and the problem still persist.

comment:7 Changed 4 years ago by spy00

Same bug with transmission-daemon 2.83 on Openwrt (AA 12.09 rc2);

just finished torrents do not honor the queue setting unless they are stopped and started again.

comment:8 Changed 4 years ago by an_idiot

  • Version changed from 2.42 to 2.84+

comment:9 follow-ups: Changed 4 years ago by an_idiot

Same issue on 2.84 (14306) on Mac OSX 10.9.5. Is this bug very hard to fix?

Also, if you shutdown transmission and restart the program, Even the download maximum doesn't get applied. All torrents just start, even if you have 20 of them.

comment:10 in reply to: ↑ 9 Changed 4 years ago by cfpp2p

Replying to an_idiot:

Same issue on 2.84 (14306) on Mac OSX 10.9.5. Is this bug very hard to fix?

No, it is not hard to fix. But I am unclear of the logic for some possible scenarios.

For instance, suppose I have set my download queue to 5 and the upload queue to 2.

In this case I now have 7 torrents uploading. One download finishes goes to seeding state, and another download starts. Now I have got 5 downloading/seeding and 3 seeding, but what is the preference for which one of the three pure seeds to stop?

If I stop the just finished download torrent and it is a private torrent I would get a 'hit and run' flag, not good.

I do not see why necessarily stop the seed with most recently finished download time. Why not one of the previous seeds with the highest or lowest ratio, or the one with the lowest or highest average upload rate. It is unclear to me which of the seeds to queue and simply choosing the one that was most recently downloading seems wrong to me. Maybe I would want to stop and queue the torrent that's been seeding the longest.

What might seem a simple fix is not really so if we want to include the choices many users would require for deciding which seed to queue up.

I think simply choosing to queue the most recently downloading would cause some issues for users.

What placement order in the queue should the decided upon torrent go. To the top of the queue or the bottom?

One simple way we have already got to immediately stop a torrent from going directly from downloading to seeding is to set a very low or zero seed ratio. Then the user must change the ratio and start it to seed queue. In this way we can keep a very large number of seeding torrents from occurring automatically.

It is questions like these and that each user may have their own specific preference that would make a seemingly simple fix more complex than it seems on the surface.

Also, if you shutdown transmission and restart the program, Even the download maximum doesn't get applied. All torrents just start, even if you have 20 of them.

This should be fixed by r14208 and #5427 so I do not understand what you are experiencing. Please provide more information.

Last edited 4 years ago by cfpp2p (previous) (diff)

comment:11 in reply to: ↑ 9 Changed 4 years ago by x190

Replying to an_idiot:

Also, if you shutdown transmission and restart the program, Even the download maximum doesn't get applied. All torrents just start, even if you have 20 of them.

Tested with 2.84+ and it worksforme.

Note: See TracTickets for help on using tickets.