Version: 3.2 (using 4.1.80 (KDE 4.1.80 (KDE 4.2 Beta1)), compiled sources) Compiler: gcc OS: Linux (x86_64) release 2.6.26-1-amd64 Random play sometimes stops unexpectedly and previous action is not working.
This still occurs in KDE 4.2 beta 2! Arch Linux (kdemod), 4.2 beta 2 running kernel 2.6.27, i686. gcc (GCC) 4.3.2 KDE Version 4.1.85 (KDE 4.2 Beta2)
Created attachment 29792 [details] patch for playermanager removing the m_file check at slotNeedNextUrl Hi, The cause of this is the code in playermanager.cpp line 429-432 if(m_file.isNull()) { return; } Maybe this is in there for a reason, but I havn't found it yet. m_file is in this case always null, since slotFinished (which is emitted when a track finishes) sets m_file = FileHandle::null(); I think setting m_file to FileHandle::null has a good reason, but the check in slotNeedNextUrl does not really make sense. I just kicked out the part of slotNeedNextUrl, and till now it works properly. patch attached. Kind regards, Georg
Considering further debugs, it could be that it is located somewhere else. Frist time when I run juk, and press "play", the following output I got: juk(24979) PlayerManager::play: play juk(24979) PlayerManager::slotStateChanged: Phonon stopped Why should phonon be stopped in this case? It's playing? There, m_file is set to null, means no more further playing. If it stopped, and I press play again, the following happens: juk(24979) PlayerManager::play: play -> plays the whole track when the track finishes juk(24979) PlayerManager::slotNeedNextUrl: aboutToFinish juk(24979) PlayerManager::slotStateChanged: Phonon stopped and the next track plays. The question is: why does phonon make juk believe that phonon stopped playback? So - my patch is "dirty" i guess ;-) .. Kind regards, Georg
It's actually a phonon bug, not a JuK one. I could finally backtrace it (thanks for the documentation link which Kevin Krammer gave me). I added a MediaObject mo to the class PlayerManager, and remvoed the creation of mo in crossfadeToFile - just setting mo = m_media instead of that. For debugging reasons, I added outputs if mo->state() or m_media->state() is going on StoppedState, since I thought it would be the old object still in connection for some reason. Definitely not. It's m_media changing to Phonon::StateStopped. I verified the file source, yes, it's actually the file playing changing to StateStopped (which has just started playing). Quite strange - isn't it? Obviously a problem in Phonon.
Question: Is it inteded that setMediaObjects emits Phonon::Stopped? If so, it's simply wrong that PlayerManager::slotStateChanged sets m_file = FileHandle::null(). If not, it's to be considered as a phonon bug. I think the playermanager needs some general rework on how to handle the crossfading.
Created attachment 30439 [details] Bugfix (playermanager) Fixed above. Phonon initializes a new MediaObject with Phonon::LoadingState, and changes to Phonon::StoppedState afterwards. So this patch adds not to honor changes fro LoadingState to StoppedState. Works perfectly for me.
Georg, thanks for the patch, I'm testing it right now. I've experienced random JuK stoppages before so I'm going to see if I can reproduce or not with the patch applied before I commit and close this bug.
SVN commit 913907 by mpyne: Apply patch by Georg Grabler to avoid clearing our m_file in the PlayerManager if we did reach the StoppedState from LoadingState (which is how Phonon creates its MediaObjects). I could never reproduce this one but randomly so I'm going to run this some more before I backport. CCBUG:176329 M +4 -4 playermanager.cpp M +1 -1 playermanager.h WebSVN link: http://websvn.kde.org/?view=rev&revision=913907
Created attachment 30443 [details] attached my jukrc - probably helpful to reproduce Hi Michael, This bug is not even close to be just "random". At least here, it was fully reproduceable all the time: 1.) opened JuK (eh, really?) 2.) I just selected "play" in the collection list (not selecting anything) 3.) I pushed the slider of the track to it's end. Playback stopped. Options: LoopPlaylist on Use Random Play Note: This never happens by pressng "next" in JuK.
Georg, I've done some testing and coding over the past few days, and here's my results: I can reproduce the bug as reported by Georg by moving the slider immediately to its end. However phonon-xine and phonon-gst seem to differ in their behavior in this situation. Both stop playback but only phonon-xine emits the "finished()" signal. So when I was using phonon-gst and trying to fix the behavior in our slotFinished handler nothing was working. But the reason I use phonon-gst is because it handles crossfading better. :-/ However I haven't had playback randomly stop on me since applying the stateChanged patch so I believe that fixes the reporter's issue (and I will backport to 4.2.1). I will probably tweak playback a bit more to see if I can get everyone to play nice for 4.3 however.
SVN commit 915880 by mpyne: Only stop playback if the stopped event came while we were playing (instead of the normal Loading -> Stop) sequence if JuK didn't commence playback quickly enough. Backported from trunk, will be in KDE 4.2.1. BUG:176329 M +4 -4 playermanager.cpp M +1 -1 playermanager.h WebSVN link: http://websvn.kde.org/?view=rev&revision=915880
Nice, thanks. I've never got phonon-gst working properly (havn't got it working at all, probably a problem with my gstreamer), what's one of my current worst issues if I want to play around with juk and phonon a little. That's also why I tested it with phonon-xine (and ofc reproduced the problem with phonon-xine). Strange though that phonon-gst and phonon-xine seem to emit signals differently in this case. Maybe a good idea to take a look at the handlers as well, since they should show a similar behaviour.