Version: 1.3.7 (using KDE KDE 3.4.3) Installed from: Gentoo Packages Compiler: GCC 3.4.4 OS: Linux If there is a queue and you select the "Stop after Queue" option it marks a song to stop after that one. After that you add something to the queue, it will still stop after the previously marked song. Aditionally, if you remove the last song from the queue (so the one marked to stop after), it will still have that song marked to stop after... That is strange behaviour. If that song is above the last song of the current queue, it will not stop after the queue, but at the end of the list. If the last song of the current queue is above the 'marked to stop'-song in the list, the playlist will go on until it reaches the marked song, and stop after that one is done. The correct behaviour would be to update the marked song whenever the (tail of the) queue has been changed. So if you add a song, mark that song to be stopped after, instead of the previous one and if you remove the last song, mark the previous one in the queue to be stopped after. I think now it just marks a song, and then doesn't care about it. So I think the 'Stop after queue' feature should be a 'setting' (like random) rather than a button that just sets a song to stop after.
Yes, this is because the 'stop after track' feature was originally designed to just a mark a track to stop after, and stop after it was done. Various people then asked me to make these available under the stop button; I complied, with the result as you can see. I agree with your assessment, but making it work that way would require either some redesigning or working around the existing design, and I don't know if/when I'll get around to that.
I want this feature implemented too (badly!). There is another way it could work: toggle a "stop after queue" option on when the action is requested. When the last queue reaches the last element (which has, by that time, become element number 1) and that the queue vanishes, amaroK should add the "stop after this item" option to the playey item. For example: ---------------------------------------------- 1. [Queued 1] First time song 2. [Playing ] The second girl I loved 3. [Queued 2] Three sisters 4. Four ever ---------------------------------------------- Elements in queue: 2 | Stop after queue: yes ---------------------------------------------- * 2 finishes and 4 is queued. ---------------------------------------------- 1. [Playing ] First time song 2. The second girl I loved 3. [Queued 1] Three sisters 4. [Queued 2] Four ever ---------------------------------------------- Elements in queue: 2 | Stop after queue: yes ---------------------------------------------- * 1 and 3 are played, amaroK proceeds to play 4: ---------------------------------------------- 1. First time song 2. The second girl I loved 3. Three sisters 4. [Playing|Stop] Four ever ---------------------------------------------- No queue | Stop after queue: No ---------------------------------------------- There should also be (I think) an option to choose which "stop after queue" method the user wants to use. (Some people might like the old one.) This should (I think) be not very hard to code. I do know *some* C and C++ and would be happy to give it a try, if told where to begin. (These open source projects are HUGE.)
maybe this report could be set as confirmed ("new", i think) so that it does not creep up in unconfirmed report searches ?
Confirming because of Gabor's comment.
Still present in 1.4.9.1
Unfortunately, Amarok 1.4.x is no longer actively maintained, as all the focus is on Amarok 2.0. Feel free to report any bug you should run across in Amarok 2.0