Bug 323732

Summary:	Amarok plays wrong next track after adding some track to queue
Product:	[Applications] amarok	Reporter:	Kyrylo Bohdanenko <kirill.bogdanenko>
Component:	Playback	Assignee:	Amarok Bugs <amarok-bugs-null>
Status:	CONFIRMED ---
Severity:	minor	CC:	matej, myriam, romain.perier, sitter, tdfischer
Priority:	NOR
Version First Reported In:	2.8.0
Target Milestone:	2.9
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Video recording of the bug

Description Kyrylo Bohdanenko 2013-08-19 15:24:34 UTC

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)

Comment 1 Kyrylo Bohdanenko 2013-09-22 20:00:44 UTC

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

Comment 2 Myriam Schweingruber 2013-09-22 23:09:00 UTC

well, since this is only reproducible with the gstreamer backend, this is not an Amarok bug, reassigning.

Comment 3 Matěj Laitl 2013-09-23 08:03:21 UTC

(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.

Comment 4 Harald Sitter 2013-09-23 10:31:17 UTC

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 ;)