Bug 303315 - Amarok advances to next track before the previous one stopped
Summary: Amarok advances to next track before the previous one stopped
Status: RESOLVED DUPLICATE of bug 302240
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: 2.5.90 (2.6 beta)
Platform: Debian testing Linux
: NOR normal
Target Milestone: 2.6
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-10 16:01 UTC by Ralf Jung
Modified: 2012-07-12 16:48 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Jung 2012-07-10 16:01:32 UTC
The next track shown at the top (right to the currently playing track) is updated too early: Some 2 to 20 seconds before the current track ends, the text is updated to show the track *after* the next one, and the previous track shown is actually the current one. Also, if I enqueue a new track during that period, this is ignored.
This happens for each track, but the time is very different from song to song. I am under the impression that for ogg files, it is much larger than for mp3 files.

Reproducible: Always

Steps to Reproduce:
1. Play a song and wait till shortly before it sends
2.  Observe the "next track" shown by Amarok
3. Optionally, some seconds before the previous song ends, put some title into the queue
Actual Results:  
* Some seconds before the track actually ends, Amarok updates the "next" and "previous" song
* The enqueue request is ignored, i.e. it is enqueue after the next song

Expected Results:  
* The previous and next song should be updated in sync with the current one
* The song I enqueue should be played after the current one

* I am using Debian testing with Amarok version 2.6~beta1+75.g47e75df
* This happens both with the VLC and the GStreamer backend, but the times again depend on which backend I use
* Fade-out is disabled (but it also happens with the default setting)
Comment 1 Myriam Schweingruber 2012-07-11 16:13:53 UTC
Is this a new behavior for beta? I can't reproduce this here with current git, though.
Comment 2 Ralf Jung 2012-07-11 17:05:03 UTC
I'm observing this for quite a while already, at least since 2.5.
Comment 3 Myriam Schweingruber 2012-07-12 06:40:40 UTC
About the phonon backend: did you restart KDE after changing the backend? Since KDE 4.8.0 this is necessary, else the backend change doesn't take effect. 
FWIW: I have never seen that happen with the phonon-backend-vlc and strongly suspect this to be a duplicate of bug 302240
Comment 4 Ralf Jung 2012-07-12 16:48:20 UTC
(In reply to comment #3)
> About the phonon backend: did you restart KDE after changing the backend?
> Since KDE 4.8.0 this is necessary, else the backend change doesn't take
> effect. 
> FWIW: I have never seen that happen with the phonon-backend-vlc and strongly
> suspect this to be a duplicate of bug 302240
Indeed I am unable to reproduce this with the VLC backend currently - I thought I did restart KDE, but obviously I did not. Sorry.

*** This bug has been marked as a duplicate of bug 302240 ***