If I have an mp3 track followed by an ogg track in my playlist, Amarok will not play the ogg track after the mp3 track has stopped. It works going the other way. This started happening when I upgraded to Kubuntu 12.04 from 11.10. Amarok-Diagnostics Amarok Version: 2.5.90 KDE Version: 4.8.90 (4.8.90) Qt Version: 4.8.1 Phonon Version: 4.6.0 Phonon Backend: GStreamer (4.6.0) PulseAudio: Yes Amarok Scripts: CopyAllCover 1.5 (stopped) Amarok Script Console 1.0 (stopped) Android Amarok2 Remote 0.3 (stopped) Lyricwiki .2 (stopped) Free Music Charts 1.6.0 (stopped) Librivox.org 1.0 (stopped) Cool Streams 1.0 (stopped) Amarok Plugins: AudioCd Collection (enabled) DAAP Collection (enabled) MTP Collection (enabled) MySQLServer Collection (enabled) MySQLe Collection (enabled) UPnP Collection (enabled) Universal Mass Storage Collection (enabled) iPod, iPad & iPhone Collection (enabled) Ampache (disabled) Jamendo (enabled) Last.fm (enabled) MP3 Music Store (enabled) MP3tunes (disabled) Magnatune Store (enabled) Podcast Directory (enabled) gpodder.net (disabled) Local Files & USB Mass Storage Backend (enabled) NFS Share Backend (enabled) SMB (Windows) Share Backend (enabled) Reproducible: Always Steps to Reproduce: 1.Add an mp3 track followed by an ogg track to the play list. 2.Wait for the mp3 track to finish. 3.The ogg track doesn't start playing. Expected Results: I expected the next track in the play list to start playing.
Could you please change your phonon-backend to vlc, restart KDE and try again? This is most likely a problem with the phonon backend.
This only started since upgrading to 12.04 and I was using gstreamer before without any trouble.
Still, it would be nice if you could test, the gstreamer backend is known to have problems in that regard.
OK, I've installed phonon-backend-vlc and with it enabled it plays as it did before. Looks like another problem with gstreamer in this release.
Sadly nothing new in that regard, reassigning.
*** Bug 301325 has been marked as a duplicate of this bug. ***
I found installing the phonon-backend-vlc alone wasn't good enough, you had to make it more preferred than the old gstreamer backend in the amarok config. The problem does indeed go away after a reboot.
Had an update to gstreamer this morning that according to the changelog fixed this bug: debian/patches/git_timestamps_discard_issue.patch: - "don't discard timestamps when consecutive input buffers have the same ts", should fix playback pausing on mp3 to ogg transitions in rhythmbox (lp: #921071) I've now changed back to phonon-backend-gstreamer, logged out and after logging back in it seems to have fixed this bug.
Doesn't look like it is fixed as it just happened again.
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 303580, bug 302240 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
This improves the problem, but it's still present. Previously, it would pause for a long time (I just recently discovered that it resumes about an hour later, skipping several tracks), and now it only pauses for about 10 seconds before continuing normally. Phonon-gstreamer revision: 58b12a8c7a2870f167ee699b98cd62042c3581a6 Amarok revision: 8a212613c83a97234086f1ea1abaa643578ec745
Okay, my previous comment was incorrect. The problem is still present, at the same level of severity as before. However, if you seek to near the end of the mp3 track (the way I did due to impatience), the different behavior I described occurs. Allowing the mp3 to play normally results in the long-duration pause. This may have been the case the whole time, I just didn't run into it.
I can confirm this bug in 2.5.0. From my testing, it seems that it's not a bug in GStreamer but a bug in Amarok while interacting with GStreamer, as this bug doesn't happen when playing files through KMPlayer with the Phonon backend or through gst123. So it should be reassigned back to amarok. I'll also test this with Amarok 2.6 once it hits the repositories.
(In reply to comment #13) > I can confirm this bug in 2.5.0. From my testing, it seems that it's not a > bug in GStreamer but a bug in Amarok while interacting with GStreamer, as > this bug doesn't happen when playing files through KMPlayer with the Phonon > backend or through gst123. So it should be reassigned back to amarok. pastas4, please don't make decisions that belong to developers. Using the same reasoning you make this bug doesn't exist because it is not present when vlc phonon is used. (Amarok talks just to Phonon backed in implementation-specific thing) How do you know that KMPlayer and qst123 tests all functionality on Phonon? Have you checked that they for example use gapless playback? This bug is watched by both Phonon and Amarok developers (i.e. me) so you can be assured it is assigned correctly. (taking information available in this bug to date into account)
No offence intended there, I was just sharing the results of my tests and giving suggestions. Besides, a patch to Amarok reportedly changed the issue somewhat, so it further shows that it could be a bug only in Amarok. Of course, it would be nice if it was possible to assign it to both products, but that is not so.
I just tested this in KDE 4.9 with Amarok 2.6.0 and phonon-backend-gstreamer 4.6.2, and it seems that the issue is fixed. I looped a playlist with 2 MP3 and 2 OGG files for a while, and it didn't stop once.
Seems to be resolved in phonon-gstreamer 4.6.2, good!
I have gstreamer 4.6.2 (and amarok 2.6.0) and am still sometimes seeing this issue, though in the cases where it's happened its been from an ogg track to an mp3 (or flac) is this likely to be a differnet issue or is it the same problem?
I also confirm the problem is still present, with gstreamer 4.6.2 and amarok 2.6.0.
Reopening based on comments #18 and 19
http://techbase.kde.org/Development/Tutorials/Debugging/Phonon
(In reply to comment #19) > I also confirm the problem is still present, with gstreamer 4.6.2 and amarok > 2.6.0. Can you please follow the steps outlined in http://techbase.kde.org/Development/Tutorials/Debugging/Phonon to produce a debug log?
This is interesting, I just upgraded (via clean install) to KDE 4.9, which includes Amarok 2.6.0 and phonon-gstreamer 4.6.2, and I do still get the issue, like others said, every time. So this makes me wonder why my previous test case worked better. The only difference in the sound system that I can tell off the top of my head is that in my previous test I only had ALSA installed, while now I have PulseAudio. So it might be related to that, but I'll test some more and see if I can find more about the differences between the tests. Meanwhile, I produced the debug logs, I'll attach them here.
Created attachment 74631 [details] Debug log, short This log was obtained by running this command: PHONON_DEBUG=5 PHONON_BACKEND_DEBUG=5 PHONON_PULSEAUDIO_DEBUG=5 PHONON_GST_DEBUG=5 amarok &>amarok-debug.log During the test, an MP3 track was played, then an OGG track was queued. It paused at the beginning of the track for around a minute, and then continued playing. I closed Amarok before it ended playing the OGG track.
Created attachment 74632 [details] Debug log, long This is a log with extra debugging enabled, namely this: PHONON_DEBUG=5 PHONON_BACKEND_DEBUG=5 PHONON_PULSEAUDIO_DEBUG=5 PHONON_GST_DEBUG=5 PHONON_GST_GST_DEBUG=8 amarok --debug &>amarok-debug-copious.log In this case, I played an MP3 file, queued an OGG file, waited for it to resume playing and end playing. It then went on to play the next MP3 file, and then I closed Amarok.
*** Bug 309095 has been marked as a duplicate of this bug. ***
Setting status correctly. Raising bug status and importance as this makes playing music with that backend a real problem.
I just did additional testing, and yes, this is related to PulseAudio. You can test it like this (tried on KDE 4.8.5, Amarok 2.5.0, PulseAudio 1.1, phonon-gstreamer 4.6.1, but should work on other versions too): echo "autospawn = no" >> ~/.pulse/client.conf && pulseaudio -k && amarok Or manually, set autospawn to "no" in either ~/.pulse/client.conf or /etc/pulse/client.conf, then kill PulseAudio, and then try to play tracks. It should work then, OGG tracks no longer get paused. Note that using pasuspender doesn't work, you must kill the daemon itself.
*** Bug 310261 has been marked as a duplicate of this bug. ***
(In reply to comment #25) > This is a log with extra debugging enabled, namely this: > PHONON_DEBUG=5 PHONON_BACKEND_DEBUG=5 PHONON_PULSEAUDIO_DEBUG=5 > PHONON_GST_DEBUG=5 PHONON_GST_GST_DEBUG=8 amarok --debug > &>amarok-debug-copious.log Please note that you have to use PHONON_SUBSYSTEM_DEBUG rather than PHONON_GST_GST_DEBUG since Phonon Gstreamer 4.6.0. In fact the steps outlined at https://bugs.kde.org/show_bug.cgi?id=290706#c54 also apply to this bug in case someone needs a detailed list of what to do to get debug logs. About the bug though, since unfortunately the long log from comment #25 is not actually containing gstreamer debug I am still in the dark about this issue. I fail to reproduce it with updated Kubuntu 12.04 + KDE SC 4.9 (PPA) + Amarok 2.6.0 (src) + Phonon GStreamer 4.6 (git) + Phonon 4.6 (git) so I don't see this report going anywhere without a debug log unfortunately. Also, FWIW, the short log from comment #24 is inconclusive as it contains exactly what is supposed to happen debugwise. song plays, abouttofinish is emitted, amarok sets new source, instead of ending the stream the source is changed on-the-fly and eventually gets stopped by quitting Amarok, so it would appear that perhaps one of the libraries is experiencing an overly long inter-thread locking somewhere. Finally I have a couple of questions: a) Is this reproducible with an entirely new user (i.e. a clean set of configs and an amarok where nothing was customized)? b) Is Replay Gain on (Amarok menu bar -> settings -> replay gain) if not turn it on, otherwise turn it off. Does that change anything? c) is PulseAudio running/installed? If so, what *exact* version (including distro revisions - e.g. latest on Kubuntu 12.04 is 1:1.1-0ubuntu1) c-1) if PA is running, is it used? (Can be checked by setting PHONON_PULSEAUDIO_DEBUG=5 or in the Phonon configuration module which only shows the 'Audio Hardware Setup' tab when PA is used) e) What is the exact version of gstreamer, phonon, phonon-gstreamer and amarok (including distro) If you know how, it would also be greatly appreciated if you could try to reproduce the issue with phonon gstreamer 4.6 from git (branch: 4.6).
Change status accordingly
To answer your questions: a) Yes, it is reproducible even on a clean installation of openSUSE 12.2. I believe that this can be tested by using the KDE LiveCD offered for download on their website. I also built my own LiveCD using SUSE Studio to check this issue. I could also give you a link to it, if you want to check that as well. b) Tested when it was on Track. Disabling it makes no difference. c) Yes, it only happens when PulseAudio is running (happens even if pasuspender is used, but no longer happens if PA is killed). The current version of it that I am using is 1.1-6.4.1. e) amarok 2.6.0-169.1, libphonon4 4.6.0-90.1, phonon-backend-gstreamer-0_10 4.6.2-30.1 I'll see if I can get a workable log with PHONON_SUBSYSTEM_DEBUG (the log I get when using all the options together is more than 900 MiB in size, so obviously it cannot be uploaded anywhere to begin with), and possibly build the applications from source.
Simply compress the log, xz -9 foo.log should do the trick.
Created attachment 75356 [details] Debug log, with PHONON_SUBSYSTEM_DEBUG=3 Since anything above level 3 debug did not fit, I used it instead of level 5. The exact command line was this: PHONON_DEBUG=3 PHONON_BACKEND_DEBUG=3 PHONON_GST_DEBUG=3 PHONON_SUBSYSTEM_DEBUG=3 PHONON_PULSEAUDIO_DEBUG=3 amarok --nofork --debug &> amarok-pulse-3.log Interestingly, there are gst_pulsering_stream_overflow_cb messages just as the OGG track starts playing, and it even refers to 0:02 seconds.
Upstream bug fixed as per http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=3880323
Here, bug always present with amarok 2.8 and gstreamer0.10-base 0.10.36-1
(In reply to comment #36) > Here, bug always present with amarok 2.8 and gstreamer0.10-base 0.10.36-1 Because the fix is in gstreamer master == 1.x, not 0.10.x Ask your distribution to patch it.
This bug is not really resolved, is it? If the root cause is fixed in Gstreamer 1.0, does this actually fix the problem in Amarok? Is it possible to use Gstreamer 1.0 with Phonon?
Not yet, but the Phonon developers are working on it.