Bug 303981

Summary: First song after Amarok startup will be played twice
Product: [Applications] amarok Reporter: MarkusH <info>
Component: PlaylistAssignee: Amarok Developers <amarok-bugs-dist>
Severity: normal CC: info, rdieter, teo
Priority: NOR    
Version: 2.5-git   
Target Milestone: 2.6   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: Amarok debug output

Description MarkusH 2012-07-23 21:50:58 UTC
In the current git version (eae346590d33d4ca8ebf30ae8da6adb1f38f96d0) the first song after starting Amarok will be played twice.

After the first song ended, the second song should be played. Instead the first song will be played again, but the OSD, wiki, etc show the information to the second song. After the first song (played as second song) ended, the third song from the play list will be played. The OSD, etc shows the correct information.

Reproducible: Always

Steps to Reproduce:
1. Start Amarok with an existing playlist with more than 3 files from the previous session.
2. Press the Play button. Do *NOT* explicitly select a song from the playlist!
3. Wait for the first song to finish
4. The first song will be played again, but the information to the second song will be shown.
5. Wait for until the song ended (again)
6. The third song from the playlist will be played

Expected Results:  
I expect that not only the information to the second song is shown but that the song is actually played.

Linux (x86_64) release 3.5.0-1-ARCH
Comment 1 MarkusH 2012-07-23 21:51:51 UTC
Created attachment 72713 [details]
Amarok debug output
Comment 2 MarkusH 2012-07-23 22:30:31 UTC
Git revision e3f6ffa829f661151a90fdd81091e1083c75922c (as recommended in IRC) contains this bug too.
Comment 3 Rex Dieter 2012-07-24 14:25:03 UTC
Do you happen to be using phonon-gstreamer-4.6.1 ?

If so, it's a known regression between amarok/phonon-gstreamer , dup of bug #303580
Comment 4 MarkusH 2012-07-24 14:53:37 UTC
Yes, I use gstreamer. Thanks for link to existing bug.
Comment 5 MarkusH 2012-07-24 14:54:18 UTC

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