According to Matěj Laitl (https://bugs.kde.org/show_bug.cgi?id=302240#c17): > Due the the way playback works with Phonon (especially if we want to support gapless playback), we must tell Phonon what track to play next a couple of seconds before the current one ends (19s for you), if the track to play next changes in this time, we simply fail to update it. It it a minor bug, please report it as a new one. (please search whether it is already reported before) Reproducible: Always Steps to Reproduce: 0. Turn on shuffling (works with "Standart" track progression also) 1. Set track for about ~5s from the end (i.e. if track is 3:30 in length, you should set ~3:25) 2. Pause Amarok (this step is not required, it's just for convenience) 3. Enqueue some other track (e.g. "Aaa - Bbb") 4. Hit "Play" button and wait until current track ends Actual Results: Random track starts playing and "Aaa - Bbb" is next in queue. Expected Results: Track "Aaa - Bbb" should start playing This bug is reproducible when using GStreamer phonon backend (and is not reproducible with VLC phonon backend)
Created attachment 82460 [details] Video recording of the bug Here's a video illustration of bug (please note amarok's behaviour between 0:41-1:08): * Both tracks in queue are marked as (1) * (1) marker dissapears from 12-th track before current track ended
well, since this is only reproducible with the gstreamer backend, this is not an Amarok bug, reassigning.
(In reply to comment #2) > well, since this is only reproducible with the gstreamer backend, this is > not an Amarok bug, reassigning. Not, really, I confirm this is an Amarok bug, although not easy to fix one. (already stated in https://bugs.kde.org/show_bug.cgi?id=302240#c17 linked from the Description) The reason it is not reproducible with VLC is that VLC has different timing of the aboutToFinish() signal, but it doesn't make it a gstreamer bug.
It's why gapless madness is bad :P I don't think you'll be able to resolve that with present API though. We have no interface to communicate that a gapless transition should be aborted, which is what would be required to solve the issue. You can however try to fake that by either setting a prefinishMark or simply acting to the time tick, if length - tick < 1000msc && abortGapless: mo->stop(); // will state transit to stopped state of course since time ticks are queued signals that can either cut a song short or play the beginning of the gapless track for half a second or so (all depending on how busy the mainloop is). I am not sure an API solution would be much nicer internally, only hope there is that EOS handling of gstreamer allows for sufficient control and timing. Alternatively you could decide to simply not support gapless playback anymore ;)