When there's about 19 seconds of current traack left Amarok switches to next song from queue (i.e. in the toolbar and queue mark dissapears from playlist). But queued track starts normally after current one has ended. (See attached screenshots) Reproducible: Sometimes Steps to Reproduce: 1. Turn on shuffling 2. Launch one track(A) and queue another(B) 3. Wait until only about 19 seconds of current track left Actual Results: 1. Track A turns as current and previous in toolbar 2. Track B dissapears from toolbar (probably it must be current instead of A) 3. Queue mark is removed from track B. 3. Another track (C) appears in toolbar as next track. Expected Results: At the end of track A: 1. A becomes prevous, B becomes current, C becomes next when A has ended 2. Queue mark removed from B only when A has ended
Created attachment 71988 [details] Starting to play track B, normal state I would like to mention that issue happens only on certain tracks. ( Can provide one as an example. )
Created attachment 71989 [details] 19 seconds of track B left
Also these might be related: https://bugs.kde.org/show_bug.cgi?id=291805 https://bugs.kde.org/show_bug.cgi?id=299019
Which phonon backend do you use? As for the bugs you mentioned, one is not reproducible by the Amarok team,the other one is a corner case and probably not a bug anyway. Would be nice if you could test with Amarok 2.6 beta1.
I'm using GStreamer 4.6.0 as backend. The issue is still there in amarok 2.5.90 (2.6 beta1 from here: https://launchpad.net/ubuntu/+source/amarok )
Also would like to mention that issue repeats on FLAC and ALAC tracks more frequently. (mp3's are OK)
Everything's OK when using VLC 0.5.0 phonon backend
(In reply to comment #7) > Everything's OK when using VLC 0.5.0 phonon backend Yes, that is not surprising as this is most likely a problem with the phonon-backend-gstreamer. Probable duplicate of bug 277197, bug 296100 and/or bug 301325 Please install these environment variables: $ export PHONON_DEBUG=5 $ export PHONON_BACKEND_DEBUG=5 $ export PHONON_PULSEAUDIO_DEBUG=5 $ export PHONON_VLC_DEBUG=5 $ export PHONON_GST_DEBUG=5 Then restart Amarok and provide the konsole output when that happens. To pipe the output please use this command: amarok -d --nofork 2>> output.txt
Created attachment 72075 [details] stderr when amarok -d --nofork and debug env's set I'v enabled GStreamer phonon backend and started exactly the same track. The lines 40029-40092 appeared on 20 seconds before the track ended. Then I've exited amarok.
Marked as unconfirmed.
*** Bug 303315 has been marked as a duplicate of this bug. ***
Git commit e1d2ea6ce3ef61af5dcd4f99db9fb407c95ccb2d by Matěj Laitl. Committed on 24/07/2012 at 10:59. Pushed by laitl into branch 'master'. EngineController: don't do serious work in slotAboutToFinish() ...because slotAboutToFinish() may be called twice (or not at all) per track by some Phonon backends (hi, vlc) - increase play count rather in slotNewTrackPlaying() or in slotFinished(). This also needs to change how m_currentTrack is handled, because slotNewTrackPlaying() needs to have the old one in m_currentTrack. Also, PlaylistActions::requestNextTrack() is changed to be a read-only method that shouldn't change playlist state especially when there is no next track. PlaylistActions::reflectPlaybackFinished() is introduced to do the thing and is called from EngineController::slotFinished(), which is a much better place for it than slotAboutToFinish(). Reporters of CCed bugs, please re-test your bug with this commit applied, it is possible it has been resolved by this patch. Related: bug 299890, bug 268892, bug 277197, bug 302652, bug 303580 FIXED-IN: 2.6 M +1 -0 ChangeLog M +44 -35 src/EngineController.cpp M +17 -16 src/playlist/PlaylistActions.cpp M +8 -0 src/playlist/PlaylistActions.h http://commits.kde.org/amarok/e1d2ea6ce3ef61af5dcd4f99db9fb407c95ccb2d
(In reply to comment #12) > http://commits.kde.org/amarok/e1d2ea6ce3ef61af5dcd4f99db9fb407c95ccb2d You've made a mistake in comment https://projects.kde.org/projects/extragear/multimedia/amarok/repository/revisions/e1d2ea6ce3ef61af5dcd4f99db9fb407c95ccb2d/diff/src/EngineController.cpp line: 364
(In reply to comment #13) > (In reply to comment #12) > > http://commits.kde.org/amarok/e1d2ea6ce3ef61af5dcd4f99db9fb407c95ccb2d > > You've made a mistake in comment > https://projects.kde.org/projects/extragear/multimedia/amarok/repository/ > revisions/e1d2ea6ce3ef61af5dcd4f99db9fb407c95ccb2d/diff/src/EngineController. > cpp > > line: 364 If you mean the typo, then it is realy unimportant for now. I'd be much more grateful if you could rather test if the changes solve the bug for you.
Seems to be fixed in GStreamer 4.6.2.
Sorry for reopening, but I've encountered the issue again with: Kubuntu 13.04 x86_64 KDE 4.11 (from backports ppa) Amarok 2.8.0 GStreamer 4.6.3 Steps to reproduce: 0. Turn on shuffling 1. Set track for about >20s from the end (i.e. if track is 3:30 in length, you should set ~3:12) 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 Expected results: Track "Aaa - Bbb" should start playing Actual results: Random track starts playing and "Aaa - Bbb" is next in queue.
(In reply to comment #16) > Sorry for reopening, but I've encountered the issue again with: > Kubuntu 13.04 x86_64 > KDE 4.11 (from backports ppa) > Amarok 2.8.0 > GStreamer 4.6.3 > > Steps to reproduce: > 0. Turn on shuffling > 1. Set track for about >20s from the end (i.e. if track is 3:30 in length, > you should set ~3:12) > 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 > > Expected results: > Track "Aaa - Bbb" should start playing > > Actual results: > Random track starts playing and "Aaa - Bbb" is next in queue. Kirill, this is another bug, an Amarok one this time. 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)