Version: 2.3-GIT (using KDE 4.4.1) OS: Linux Installed from: openSUSE RPMs If one has a playlist sorted by rating > play count it might look like this: song 1: play count 23 song 2: play count 12 song 3: play count 8 song 4: play count 10 song 5: play count 12 song 6: play count 1 song 7: play count 0 song 8: play count 0 song 9: play count 0 song 10: play count 0 If one double-clicks, i.e. plays song 9 amarok will jump to song 7 after song 9 has finished instead of sticking to the playlist.
Teo, any idea?
Yeah, I just reproduced it, it's cause by the fact that track 9 after being played gets a play count=1, and the next track after track 9 isn't track 10 any more, but the first track after the last track with play count =1, which is track 7.
I think the general question that has to be answered before fixing this issue is whether the next track is determined by the playlist or some non-visible mechanism. IMHO if "random tracks" is disabled amarok must stick to the playlist, i.e. the user expects amarok to play one song after the other and if the user jumps some tracks, i.e. double-clicks one, amarok should continue the playlist from there on. If this is not the way it is supposed to work then the user gets confused because although the playlist shows xy as the next track it is not played as the next track. In fact even amarok itself gets confused because the toolbar shows song 10 as the next song and not song 7. What I would suggest is to apply the sorting mechanism to the playlist on every start of amarok and after that just stick to the playlist as it is displayed to the user. If the user does not like the order he will change it and if so expects amarok to stick to his changes. I did not try this yet but if song 7 is palyed because it has play count = 0 then song 9 would have to be skipped since in the "next track logic" it is not at that position anymore but somewhere before song 7. Yet I guess that amarok will play it anyway, defeating it's own logic which it applied when jumping to track 7 after finishing track 9.
*** This bug has been marked as a duplicate of bug 224003 ***