Version: rev. 909419 (using Devel) OS: Linux Installed from: Compiled sources I'm not able to reproduce reliably by using local mp3 tracks, but I can with internet radio: - start amarok, clear playlist, stop any track playing. - Open internet tab, click "shoutcast directory", enter search term e.g. "polskastac", expand results - drag e.g. 10 radio stations into playlist. - start playing the first one - skip until amarok stops playing - try some tracks from local collection, those should be unplayable too. At this point only restarting helps (if it stucks in systray, kill it).
Ok, I'll look into this. I can confirm the problem, as it has happened here too.
oops, sorry.
@Reporter: What KDE version are you running?
KDE 4.1.87 (KDE 4.2 >= 20090101) (opensuse packages)
KDE 4.1.96, Debian-Packages I had this problem with phonon-xine-backend With phonon-gstreamer-backend amarok works fine.
As I said on irc, this happened to me at least 3-4 times since I upgraded to amarok trunk, I don't think it's a KDE problem. After some hours of playback amarok would just stop and refuse to play anything else. KDE: 4.2.60 (KDE 4.2.60 (KDE 4.3 >= 20090106))
by trunk I meant 2.1 :)
@Kristjan: I can't reproduce the problem any more with the latest SVN. I did some changes today, maybe that affected it. Could you svn update and try again?
(In reply to comment #8) > @Kristjan: I can't reproduce the problem any more with the latest SVN. I did > some changes today, maybe that affected it. > > Could you svn update and try again? > rev. 910586 still reproducible. If you skip a bit faster you'll probably hit it.
*** Bug 181181 has been marked as a duplicate of this bug. ***
finally i managed to get some output when this happens. This is the output when double-clicking any song in the playlist: amarok: BEGIN: void Playlist::Actions::play(quint64, bool) amarok: BEGIN: void EngineController::play(const Meta::TrackPtr&, uint) amarok: BEGIN: void EngineController::playUrl(const KUrl&, uint) amarok: BEGIN: void EngineController::slotStopFadeout() amarok: END__: void EngineController::slotStopFadeout() - Took 8.9e-05s amarok: [EngineController] URL: "file:///mnt/mybook/Torrents/Heartless%20Bastards~The%20Mountain%20%5BV0%5D-2009/11%20-%20Sway.mp3" amarok: BEGIN: void EngineController::slotNewTrackPlaying(const Phonon::MediaSource&) amarok: [EngineController] Using gain of 0 with relative peak of 0 amarok: BEGIN: void EngineSubject::stateChangedNotify(Phonon::State, Phonon::State) amarok: END__: void EngineSubject::stateChangedNotify(Phonon::State, Phonon::State) - Took 9.1e-05s amarok: BEGIN: void Amarok::TrayIcon::setupToolTip() amarok: END__: void Amarok::TrayIcon::setupToolTip() - Took 0.00018s amarok: BEGIN: virtual void ProgressWidget::engineTrackLengthChanged(long int) amarok: new length: 322 amarok: slider enabled! amarok: END__: virtual void ProgressWidget::engineTrackLengthChanged(long int) - Took 0.00027s amarok: BEGIN: virtual void ScrobblerAdapter::engineNewTrackPlaying() amarok: [lastfm] track type: "mp3" amarok: BEGIN: void ScrobblerAdapter::checkScrobble() amarok: END__: void ScrobblerAdapter::checkScrobble() - Took 0.00012s amarok: [lastfm] nowPlaying: "Heartless Bastards" - "The Mountain" - "Sway" amarok: END__: virtual void ScrobblerAdapter::engineNewTrackPlaying() - Took 0.00049s amarok: BEGIN: void Playlist::DynamicTrackNavigator::appendUpcoming() amarok: END__: void Playlist::DynamicTrackNavigator::appendUpcoming() - Took 0.00012s amarok: END__: void EngineController::slotNewTrackPlaying(const Phonon::MediaSource&) - Took 0.0038s amarok: END__: void EngineController::playUrl(const KUrl&, uint) - Took 0.0044s amarok: END__: void EngineController::play(const Meta::TrackPtr&, uint) - Took 0.0046s amarok: END__: void Playlist::Actions::play(quint64, bool) - Took 0.0048s And after few seconds: HTTP POST: "http://post.audioscrobbler.com:80/np_1.2&a=Heartless%20Bastards&t=Sway&b=The%20Mountain&l=353&n=0&m=" amarok(28981) ScrobblerHttp::createRequest: PostOperation: QUrl( "http://post.audioscrobbler.com:80/np_1.2" ) amarok(28981) KNetworkReply::setMimeType: "text/plain" "OK" And that's it: it doesn't play anything. I'm running everything from trunk: phonon, kde, amarok...
I'm very similiar problem with Amarok 2.0.1. When I try to play my personal last.fm radio it plays fine but only one track, after that it simply stops playing. I can double click on item in play list and it starts playing again (another one track). Here is amarok's output: HTTP GET "http://post.audioscrobbler.com/?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" "OK 15d1c9d612ab49ad9af8e51a37d8e2ab http://post.audioscrobbler.com:80/np_1.2 http://post2.audioscrobbler.com:80/protocol_1.2" "session=077c80394093ac81f1821e625536b434 stream_url=http://195.24.233.49:80/last.mp3?Session=XXXXXXXXX subscriber=0 framehack=0.. base_url=ws.audioscrobbler.com base_path=/radio info_message= fingerprint_upload_url=http://ws.audioscrobbler.com/fingerprint/upload.php permit_bootstrap=0" QUrl( "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" ) "response=OK url=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX stationname=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX discovery=true" "No recs :(" WARNING: GOT NULL NODE IN COPY CONSTRUCTOR! WARNING: GOT NULL NODE IN COPY CONSTRUCTOR! WARNING: GOT NULL NODE IN COPY CONSTRUCTOR! "<playlist version="1" xmlns:lastfm="http://www.audioscrobbler.net/dtd/xspf-lastfm"> XXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXX </trackList> </playlist>" QString::arg: Argument missing: Amarok - Nie jest odtwarzany żaden utwór., 0:00 QString::arg: Argument missing: Amarok - Nie jest odtwarzany żaden utwór., 0:00 QString::arg: Argument missing: Amarok - Nie jest odtwarzany żaden utwór., 0:00 QString::arg: Argument missing: Amarok - Nie jest odtwarzany żaden utwór., 0:00 QString::arg: Argument missing: Amarok - Nie jest odtwarzany żaden utwór., 0:00 HTTP POST: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" "OK" TooShort "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" QString::arg: Argument missing: Amarok - Nie jest odtwarzany żaden utwór., 0:00 HTTP POST: "http://post.audioscrobbler.com:80/np_1.2&a=XXXXXXXXXXXXXXXXXXXXXXXXXXXX" "OK"
I believe you should blame xine 1.16.1 for this (or phonon xine backend which does not seem to work well with xine 1.16.1). From what I have seen so far, xine 1.16.1 appears to be a pretty broken release. At least it breaks Last.fm "Skip" for me. So what version of xine do you have? If you are running debian sid, I recommend installing xine 1.14 from debian testing and retesting if the issue persists.
(In reply to comment #13) > I believe you should blame xine 1.16.1 for this It's not xine 1.16.1 because I only updated it 2 days ago (I had 1.16 before). But I've had this bug before I upgraded.
I'm having the same issue on opensuse with KDE 4.1.2, Amarok 2.0.1 and xine 1.16.1 I think it may be due to xine as I only noticed this issue after upgrading it.
semi-same issue on Gentoo (kde-testing overlay) Software: amarok: Version 2.0.1 Using KDE 4.1.96 (KDE 4.1.96 (KDE 4.2 RC1)) $ xine-config --version 1.1.16.1 phonon using xine backend. Symptoms: I can semi-reliably reproduce this by pausing play and coming back some time later, which could be ten minutes or could be several hours. Amarok's GUI stays responsive, it just won't play anything. When trying to quit, even the GUI locks up. When this happens, the progress bar on top of the screen becomes full until the stop button is hit, then it becomes empty but still won't play. killing amarok and restarting it solves the problem. the kill command does not require any flags to kill amarok, meaning that SIGTERM is enough to kill it. It does not require SIGKILL. Upon attaching a GDB instance, it reports a thread locked in __kernel_vsyscall(). Ideas for possible causes: a) Race condition of some kind... but b) is more likely b) xine/amarok locked in syscall (__kernel_vsyscall), phonon thread blocks, doesn't check for quit flag when amarok is quitting, gui locks up when waiting for phonon thread. I'll respond to any requests for data, as this occurs to me often (about 3x per day), so if there's a request and some info on how to get the required data via gdb, I'll gladly oblige.
*** Bug 181664 has been marked as a duplicate of this bug. ***
*** Bug 181867 has been marked as a duplicate of this bug. ***
I've got the same problem as described using; Fedora 10 KDE 4.2 (KDE-RedHat) Amarok SVN (in this case built on 20-01-2009 but more recent revisions too) phonon.i386 (4.3.0-2.fc10) phonon-backend-xine.i386 (4.3.0-2.fc10) xine-lib-*.i386 (1.1.16-1.fc10)
I;m repeating myself, but could somebody actually retest with xine 1.14?
Modestas Vainius, I would, if I could. I'll try to give it a shot under FC10 this weekend. Might be a bit hard for me to do since I haven't been able to find any rpm's for it (so far). I'd have to build manually, I guess.
*** Bug 182583 has been marked as a duplicate of this bug. ***
*** Bug 178239 has been marked as a duplicate of this bug. ***
*** Bug 182862 has been marked as a duplicate of this bug. ***
I confirm this by playing only local audio files. No need to add radio station to reproduce.
For me, pausing playback is a VERY effective way of triggering this bug, although it also happens somewhat frequently just from normal playing of tracks on the local disk.
One more data point: killing and restarting the pulseaudio server seems to kick amarok out of its frozen state at least sometimes, although I'm pretty sure that it's not pulseaudio that triggers the bug as I'm fairly certain I also saw it with pulseaudio disabled.
Same story for me too; pausing ends up (eventually) rendering amarok unresponsive. From what I recall, this has been the case for me since 2.0. This unfortunately is a show-stopper for me using amarok until it gets fixed. Killing processes and restarting amarok gets old real quick.
Is there *anyone* who has this problem with Xine < 1.16 ? Afaics, this bug didn't happen with Xine 1.15.
I can confirm the same problem with Debian and Kde 4.2 (I'm using libxine1-bin 1.1.16.1-2). I've just downgraded libxine1-bin, libxine1-ffmpeg, libxine1-x and libxine1-misc-plugins to version 1.1.14-5 from Lenny. Seems to be working fine. I can also confirm that I have no problems using gstream phonon backend instead of xine
*** Bug 183165 has been marked as a duplicate of this bug. ***
I can confirm that downgrading to media-libs/xine-lib-1.1.15-r1 on Gentoo solved it for me.
(In reply to comment #32) > I can confirm that downgrading to media-libs/xine-lib-1.1.15-r1 on Gentoo > solved it for me. > I was just about to post this! :D I've been using 1.1.15 for almost 10 hours now: Amarok hasn't stopped yet :)
Now I have to ask a favor of you users and testers: Who's willing to contact the xine devs and inquire about possible reasons / solutions / workarounds for these problems? :) If anyone could do this, we Amarok devs would appreciate it greatly! :)
Hi: I've already sent an e-mail to one of Xine's developers. I'll post here the results as soon as I have them... Pedro
Hi all: Here goes the answer I got from the mail I sent to a Xine developer (actually he's not developing it any more, but still his response might help...): "Last month I've noticed a similar problem when i updated from latest hg. kaffeine was freezing on track changing. It *seems* this changeset was the culprit: Changeset: ce60f8b5995a "Prevent another possible hang on stream stop (demuxer waiting for audio out)." I have not checked if they reverted this changeset in current repository, but i updated to the one before that and it worked. I would suggest you the following: 1) compile xine from source (hg repository) and try it. they might have fixed it already. (compiling xine from source is easy, we have few dependencies. make sure you have ffmpeg-devel installed) 2) if it doesn't work try the changeset before the one above (2c5059a74b28) 3) confirming that this is a problematic changeset you may post to xine-devel. if you prefer, let me know about your findings and i can post it myself. ps: xine hg url http://hg.debian.org//hg/xine-lib/xine-lib http://hg.debian.org//hg/xine-lib/xine-lib?cmd=changeset;node=ce60f8b5995a ----------------------" Next steps? Pedro
Many Thanks, Pedro. It would seem the best we could do is contact the distro packagers (we Amarok developers have a direct connection with most of them) and somehow work out with them how a bugfix patch for libxine (if one exists) could be distributed to the users. It could probably be done with an online update, but unfortunately many distros will only do online updates for security fixes, but not for normal bugfixes. So I'm not sure how to proceed here, any help and ideas are appreciated :)
I believe the best way to begin is really just to let the packagers to know that there's a problem and maybe a solution as well. I don't know the situation with other distros, but I think with openSUSE this might be easier to fix. Because anyone running Amarok on oS is likely get their xine from an external repository (Packman) and they should have no problem updating the package... As an oS + Packman user (and hoping to get a fix for this as well) I can send the mail to the xine packager there, unless you Amarok devs want to take care of this yourselves.
As a Debian user myself, I've filled a bug against libxine (#514114). I'm going to forward them the info from the xine developers and seed what they say...
Reverting that commit doesn't actually solve anything. I just tested.
*** Bug 183360 has been marked as a duplicate of this bug. ***
Hi folks. As i told Pedro, i have not been involved with xine development for more than a year now but i'd like to share some thoughts. This sounds like a serious issue to me (pretty annoying at very least). I have read the other duplicated bug reports and, IMHO, you have two entirely different issues here: 1) xine freeze while changing tracks. I noticed this myself about one month ago but i couldn't really understand what was going on (some "impossible" stuff happening inside libxine, gdb going nuts...). I've tried to reproduce it yesterday but i was not able to. 2) xine freeze when pausing/unpausing. This was very easy to reproduce and cursory investigation shows that xine's pulseaudio driver might be problematic. Therefore i'd like to ask people to check if they have either (1) or (2). If they have (2), please try using "alsa" instead of "autodetect" or "pulseaudio" just to confirm my theory. Sorry but i don't know how to change phonon/xine audio driver - i know amarok used to have a neat gui for doing this. Problem 2 doesn't really worries me. it was easy to reproduce yesterday and i hope it won't be difficult to fix after remembering how the pulseaudio api works, doing some debuging etc. Problem 1 is strange and not easy to reproduce. I thought the ce60f8b5995a changeset could be related but i couldn't really confirm this. Dan Meltzer reports it is not related, but we don't know if his problem is of kind (1) or (2). So lets try first to get things straight and organize information. Fortunately we have a lot of people watching this so we should be able to test a lot of cases, proposed fixes etc.
I've done a signifigant amount of digging through amarok's enginecontroller the past few days trying to find the cause of this.... I havn't found it yet, though. I've added more debug output in trunk. I have at least the first issue. I'm also experiencing another stoppage issue with http streams but its more reproducable, and likely something else. It looks to me as if Amarok is doing everything it is supposed to do. One possibility I can think of is that phonon is emitting aboutToFinish too close to the end of the song on occasion.. and we are not able to queue a new track before the old track finishes. By the time we queue it phonon may have already entered stoppedState, and then music playback may not happen? (But play should start it then...) Talking to mpyne on irc indicates that he's seen the issue with Juk as well, which also points to it being an issue somewhere further down the stack. I've added Matthias (phonon/xine maintainer) to the cc to see if he has any input into this.
Dan, if you think the finished event might be related, i suggest you trying to delay the event processing in amarok to see what happens. I guess delaying it inside xine may not have the same effect. In the meantime, i have going through the second issue. xine is definitely doing unsafe things on pausing (i'm also to blame on this part) and it happens that pulseaudio is more "sensitive" to that. in particular, try to write to a "corked" pulseaudio and it will stuck forever. since the driver's lock is held it is also impossible to "uncork" it from another thread. I have been dealing with this bug to the point that xine is not doing the unsafe sequence anymore. however pulseaudio still hangs writing to a recently "uncorked" device. Do you think it would be impolite to add pulseaudio's author to the cc list as well? It seems i may need to go into pulseaudio debugging which is something i would rather avoid...
*** Bug 183570 has been marked as a duplicate of this bug. ***
@Miguel: "Do you think it would be impolite to add pulseaudio's author to the cc list as well?" - No, I don't think that's impolite, but bugs.kde.org only accepts CC'mails for known addresses (members with accounts). So we might have to ask him first...
I'm attaching a xine-lib patch to rework the audio pausing so we never try to write to a "corked" driver. While it makes problem (2) less frequent here i can still reproduce it. I have seen a pulseaudio issue that seems related: http://www.pulseaudio.org/ticket/369 But it is supposedly fixed in 0.9.13. Updating to 0.9.14 didn't help. btw: making xine + pulseaudio the default audio path in phonon/kde was a brave decision. i would not have taken that decision myself. not that i don't think that pulseaudio is stable, but xine's driver for pulse is *much* less tested than alsa or oss.
Created attachment 31089 [details] Make xine-lib pause safe for the output driver (no write on pause) This patch is not yet committed to xine hg. Any feedback is appreciated, so if you can test it please let me know how it goes.
I too have this issue, were in the middle of a playlist, sometimes in the middle of a song even, Amarok 2.0.1 will stop playing and need a restart of Amarok to start to work again. And, my Kaffeine will hang also at times (not related to the Amarok 2 hang) so I want in on this list.
I've just tried your patch but I'm still having the issue.
Antoine: Thanks for testing! I know it doesn't completely fix the issue, but I think it is a step in the right direction (ie. playing nice with pulseaudio) so i'm interested in hearing about any possible regressions. I'm doing some progress on issue 1 as well. I hope i will have something to report in the next few days.
Created attachment 31141 [details] Fix race condition in gapless_switch Patch to fix the race condition which may cause xine to deadlock during track switching (problem 1). After some research i've found that this problem was also reported back in 2007 by Stas Sergeev but it was never fixed. Kudos to Thibaut for suggesting the nice fix.
@Miguel: you should be providing this fix to xine, not to Amarok. We don't have any influence over their code.
Seb: don't worry, i *will* commit it to xine repository. but in the meantime i thought you might want to test it and possibly confirm that it indeed fixes the issue (at least one of them).
@Miguel: thanks for the info, we really appreciate it!
I was testing your patch and the first issue still happens. Moreover when you change the track manually playback speeds up and isn't fluid at the beginning of the track ( I had this issue before last update of xine ). When I patched I had this error but it doesn't seem to have something to do with audio : Hunk #1 FAILED at 160. 1 out of 1 hunk FAILED -- saving rejects to file src/xine-engine/video_decoder.c.rej Here is the file src/xine-engine/video_decoder.c.rej (I don't know if it's helpful) *************** *** 160,169 **** running_ticket->release(running_ticket, 0); - if( !stream->gapless_switch ) stream->metronom->handle_video_discontinuity (stream->metronom, DISC_STREAMSTART, 0); buftype_unknown = 0; break; --- 160,169 ---- running_ticket->release(running_ticket, 0); + if( !(buf->decoder_flags & BUF_FLAG_GAPLESS_SW) ) stream->metronom->handle_video_discontinuity (stream->metronom, DISC_STREAMSTART, 0); buftype_unknown = 0; break;
Curiously, at worst I was hitting this issue every few songs and maybe something like once per ~ten tracks was the norm. Anyways, since updating to latest KDE4 from openSUSE on Saturday evening I've been playing music for 10+ hours pausing the playback occasionally and not once has the problem come up. Xine was not among the updated packages, but phonon-backend-xine was. Of course, the problem not showing up for a while doesn't prove anything, but there's definitely been change in the frequency is shows up, so I thought this may be of interest...
Antoine: may you replace that line in video_decoder.c by hand? With this reject the race condition is still there - the patch won't do any good.
So I patched manually the file and it seems to work well since I've been playing songs for about 10 hours and it didn't stop. Moreover the bug I mentioned (track speeding up at the beginning) doesn't happen no more :D . Maybe this patch should be tested by other people but for me it's working well. I'll go on playing songs and I'll tell you tomorrow if the bug has shown up. Thank you a lot.
I've rebuilt xine-lib yesterday evening using 2 patches attached above. I was listening Amarok for total ~12hours, and no freeze or any problems at all. Before it would freeze randomly, but more than 2hours wouldn't be possible without a freeze. I'll test it more, if i encounter any problems i report them here. Thanks Miguel for those patches :D Without them using amarok+xine was kinda annoying.
I'm testing your patch since a couple of hours and (for the moment) it works very well, i tried to make the bug happen but amarok is still playing :) i'll play music during all night and tell you if i had some problems, thanks a lot
So, i didn't have any freeze during almost 48h but a new little problem appered: sometimes there are some crackling (?) while i'm reading mp3s, often on the beggining of the titles. But that's a minor problem compared with the freezes.
SVN commit 925868 by markey: The following check is an attempt to fix http://bugs.kde.org/show_bug.cgi?id=180339 ("amarok stops playing tracks") and other issues with Phonon. The theory: It has been observed that Phonon will sometimes emit a stateChanged() with _both_ oldState and newState == 0, which makes little sense. After that it goes berserk, until you restart Amarok. Now we try to detect this weird state, and then try to destroy and recreate all Phonon objects, in the hope of fixing the situation. Fingers crossed. CCBUG: 180339 CCMAIL: amarok-devel@kde.org M +17 -1 EngineController.cpp --- trunk/extragear/multimedia/amarok/src/EngineController.cpp #925867:925868 @@ -664,10 +664,26 @@ EngineController::slotStateChanged( Phonon::State newState, Phonon::State oldState ) //SLOT { DEBUG_BLOCK - // Sanity checks + + // Sanity checks: if( newState == oldState || newState == Phonon::BufferingState ) return; + // The following check is an attempt to fix http://bugs.kde.org/show_bug.cgi?id=180339 + // ("amarok stops playing tracks") and other issues with Phonon. + // The theory: + // It has been observed that Phonon will sometimes emit a stateChanged() with + // _both_ oldState and newState == 0, which makes little sense. After that it goes + // berserk, until you restart Amarok. + // Now we try to detect this weird state, and then try to destroy and recreate all + // Phonon objects, in the hope of fixing the situation. Fingers crossed. + if( newState == Phonon::LoadingState && oldState == Phonon::LoadingState ) + { + warning() << "Trying to re-initialize Phonon. Fingers crossed."; + initializePhonon(); + newState = Phonon::ErrorState; // Indicate error + } + if( newState == Phonon::ErrorState ) // If media is borked, skip to next track { warning() << "Phonon failed to play this URL. Error: " << m_media->errorString();
(In reply to comment #42) > I have read the other duplicated bug reports and, IMHO, you have two entirely > different issues here: > > 1) xine freeze while changing tracks. [...] > > 2) xine freeze when pausing/unpausing. [...] So the xine patches discussed here seem to fix problem #1 for me -- I haven't seen that issue for a while since I updated to the latest version. I do still regularly see problem #2, though: if I leave amarok paused for any length of time, I generally have to do "pulseaudio -k" to unstick things before playing continues. Should I file that as a separate bug somewhere so that it doesn't get lost? Against amarok, pulseaudio, phonon, xine, or what?
Amarok r926795 and xine-lib-1.1.16.2-1.fc10.i386 (which holds the patches posted earlier in this report) seem to fix most (all?) the problems for me. No more problems with track freezes. I mainly had this problems with browsing through shoutcast streams. I can now hammer the previous and next buttons as much as I want without freezing Amarok. No problems with random pausing/unpausing songs. I've tried to do this a few times and no problems appear. I'm not sure if I had this bug earlier though. I never tried to reproduce it, and I usually use my keyboard's mute button instead of pause. Mary, here's a sniplet of the packages I have installed which might come in hand for comparison. amarok-2.0.70-1.20090216svn.fc10.i386 (= r926795) phonon-4.3.0-5.fc10.i386 phonon-backend-xine-4.3.0-5.fc10.i386 xine-lib-1.1.16.2-1.fc10.i386 xine-lib-pulseaudio-1.1.16.2-1.fc10.i386 pulseaudio-0.9.14-1.fc10.i386 pulseaudio-libs-0.9.14-1.fc10.i386 The Amarok package is my own package. If somebody's interested in it, let me know and I'll hook you up.
As of this moment I have problem (1) with amarok. I'm using Gentoo, and am currently running "emerge -u xine-lib" to update xine-lib to version 1.1.16.2. Miguel's patch has been included in this release. Hopefully this will solve the issue. I'll report what I find.
Some clarifications: - xine-lib 1.1.16.2 includes the patch for the problem #1 (changing tracks freeze) but not #2 (pause/resume freeze) - The patch for pause/resume freeze was just committed to xine repository and should appear in 1.1.17, i guess. - By using this patch the occurrence of pause/resume freeze reduced drastically. I believe i have completely fixed the problem from xine side so i'd account the remainder occurrences most likely as a pulseaudio bug. - I've contacted Lennart about it but i received no reply. Is he still involved with pulse?
Created attachment 31384 [details] Make xine-lib pause safe for the output driver (no write on pause) - last version Improved safe pause patch as committed to xine-lib repository (upcoming 1.1.17).
I played music on repeat in Amarok for hours today with no music-freezes and need to kill the process because of problem #1. I feel confident enough to say that xine-lib 1.1.16.2 in Gentoo no longer causes this issue. As Miguel mentioned just above, problem #2 apparently still lingers. My use of amarok has not produced that issue, though (for whatever that's worth).
*** Bug 184743 has been marked as a duplicate of this bug. ***
Well, even with latest hg xine I still have this bug on last.fm and latest svn amarok. When the track will change, Amarok stalls, and I have to skip by hand, 2 or 3 songs until it resumes playing... I had this problem a long time ago with Amarok1 too and the developers said it was a xine problem. It's a extremely annoying problem. And it seems to always come back...
*** Bug 188002 has been marked as a duplicate of this bug. ***
*** Bug 188416 has been marked as a duplicate of this bug. ***
Latest discussions [1] from our forum indicate that this problem may be related to the "Now Playing" plasmoid for the KDE desktop. Are you guys using this with Amarok 2? [1] http://amarok.kde.org/forum/index.php/topic,16614.msg27266.html#msg27266
No, I don't use any plasmoids related to Amarok 2.
Me neither.
Although a bug in the now playing applet (fixed in 4.2.2) will induce similar behaviour (more specifically, when a track is shorter than the previous track, it will skip straight to the end).
I would like to get an update on this situation, and close this report, or reassign it, in case it's not an Amarok bug (which seems unlikely). 1) We have established that using the the "Now Playing" KDE desktop widget with KDE versions lower than 4.2.2 can trigger this problem. 2) Are there still people here with KDE 4.2.2 and the latest Amarok, who are having this problem? If so, we could probably reassign it to Phonon. Personally I'm on KDE 4.2.2 and libxine 1.1.15-0ubuntu3.2, and very rarely Amarok (2.1-beta1) will stop playing tracks, and then when I try to quit it, it will hang on exit. But this happens extremely rarely, and I suspect it's a Phonon bug. I have not yet been able to detect a pattern here, so it's unclear to me what condition triggers this issue. Thoughts?
> Personally I'm on KDE 4.2.2 and libxine 1.1.15-0ubuntu3.2, and very rarely > Amarok (2.1-beta1) will stop playing tracks, and then when I try to quit it, it > will hang on exit. But this happens extremely rarely, and I suspect it's a > Phonon bug. I have not yet been able to detect a pattern here, so it's unclear > to me what condition triggers this issue. Thats exactly the behaviour I get here, too. I use Fedora 10, KDE 4.2.2, latest SVN amarok and xine-lib 1.1.16.2-3.fc10.
I got the same specs as Mathias Panzenböck and it seems to be pretty much gone for me. I haven't really experienced it since the updates to xine-lib (or at least, I can not think of a situation when it did). I'm not using the now playing applet, I guess I could give that a try to see if it (still?) breaks it.
Ok, after considering all recent comments, I think we can close this report. It doesn't make much sense to keep it open just for the sake of it, and it's got too long and confusing to be useful. If any of you folks can pinpoint the remaining issues to a specific component (Amarok, Phonon, xine, the weather..), then please open a new report at the right place. Thanks again to Miguel Freitas for the libxine fixes :)
*** Bug 189101 has been marked as a duplicate of this bug. ***
Well, I still have this bug all the time and no matter how updated is my Phonon/Xine, it keeps happening and Amarok always stucks when a last.fm track is finished (so at least for me it is NOT fixed): amarok(15860) Phonon::Xine::XineStream::event: ################################ Event: MediaFinished amarok(15860) Phonon::Xine::XineStream::event: MediaFinishedEvent m_useGaplessPlayback = true amarok: BEGIN: void EngineController::slotAboutToFinish() amarok: [EngineController] Track finished completely, updating statistics amarok(15860) EngineController::slotAboutToFinish: " " Line: 594 amarok: BEGIN: virtual void MultiPlayableCapabilityImpl::fetchNext() amarok: getting more tracks, first playing this: "Pat Metheny - Open" "Works II" amarok: BEGIN: virtual void MultiPlayableCapabilityImpl::metadataChanged(Meta::TrackPtr) amarok: BEGIN: void EngineController::slotPlayableUrlFetched(const KUrl&) amarok: [EngineController] Fetched url: KUrl("http://play.last.fm/user/4bc622466647a7f1c95e523d7b1d06bc.mp3") amarok(15860) EngineController::slotPlayableUrlFetched: " " Line: 790 amarok: [EngineController] The next url we're playing is: KUrl("http://play.last.fm/user/4bc622466647a7f1c95e523d7b1d06bc.mp3") amarok: END__: void EngineController::slotPlayableUrlFetched(const KUrl&) - Took 0.00029s amarok: END__: virtual void MultiPlayableCapabilityImpl::metadataChanged(Meta::TrackPtr) - Took 0.00051s amarok: BEGIN: virtual void Amarok::OSD::metadataChanged(Meta::TrackPtr) amarok: BEGIN: void OSDWidget::show(const QString&, QImage) amarok: END__: void OSDWidget::show(const QString&, QImage) - Took 0.0034s amarok: END__: virtual void Amarok::OSD::metadataChanged(Meta::TrackPtr) - Took 0.074s amarok: BEGIN: virtual void Meta::Album::notifyObservers() const amarok: BEGIN: virtual void CurrentEngine::metadataChanged(Meta::AlbumPtr) amarok: END__: virtual void CurrentEngine::metadataChanged(Meta::AlbumPtr) - Took 0.036s amarok: END__: virtual void Meta::Album::notifyObservers() const - Took 0.036s amarok: BEGIN: virtual void Meta::Artist::notifyObservers() const amarok: END__: virtual void Meta::Artist::notifyObservers() const - Took 7.2e-05s amarok(15860) KNetworkAccessManager::createRequest: GetOperation: QUrl( "http://ws.audioscrobbler.com/2.0/?api_key=402d3ca8e9bc9d3cf9b85e1202944ca5&artist=Pat Metheny&method=track.getInfo&sk=8d8a4ad9ed4843311cd 1f35fcd755a08&track=Open&api_sig=859277c7b3c7f4a2d6b5223a14b164eb" ) amarok: END__: virtual void MultiPlayableCapabilityImpl::fetchNext() - Took 0.11s amarok: [EngineController] The queue has: 0 tracks in it amarok: END__: void EngineController::slotAboutToFinish() - Took 0.11s amarok: BEGIN: void CurrentTrack::dataUpdated(const QString&, const QHash<QString, QVariant>&) amarok: END__: void CurrentTrack::dataUpdated(const QString&, const QHash<QString, QVariant>&) - Took 0.0005s amarok: BEGIN: virtual void CurrentTrack::constraintsEvent(Plasma::Constraints) amarok: placing album at X: 17 and Y: 9 amarok: END__: virtual void CurrentTrack::constraintsEvent(Plasma::Constraints) - Took 0.092s amarok(15860) KNetworkReply::setMimeType: "text/xml" amarok: BEGIN: virtual void MultiPlayableCapabilityImpl::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void MultiPlayableCapabilityImpl::metadataChanged(Meta::TrackPtr) - Took 0.0002s amarok: BEGIN: virtual void Amarok::OSD::metadataChanged(Meta::TrackPtr) amarok: BEGIN: void OSDWidget::show(const QString&, QImage) amarok: END__: void OSDWidget::show(const QString&, QImage) - Took 0.0023s amarok: END__: virtual void Amarok::OSD::metadataChanged(Meta::TrackPtr) - Took 0.0036s amarok: BEGIN: virtual void Meta::Album::notifyObservers() const amarok: BEGIN: virtual void CurrentEngine::metadataChanged(Meta::AlbumPtr) amarok: END__: virtual void CurrentEngine::metadataChanged(Meta::AlbumPtr) - Took 0.00031s amarok: END__: virtual void Meta::Album::notifyObservers() const - Took 0.00099s amarok: BEGIN: virtual void Meta::Artist::notifyObservers() const amarok: END__: virtual void Meta::Artist::notifyObservers() const - Took 7.3e-05s amarok: BEGIN: void CurrentTrack::dataUpdated(const QString&, const QHash<QString, QVariant>&) amarok: END__: void CurrentTrack::dataUpdated(const QString&, const QHash<QString, QVariant>&) - Took 0.00046s amarok: BEGIN: virtual void CurrentTrack::constraintsEvent(Plasma::Constraints) amarok: placing album at X: 17 and Y: 9 amarok: END__: virtual void CurrentTrack::constraintsEvent(Plasma::Constraints) - Took 0.055s "<playlist version="1" xmlns:lastfm="http://www.audioscrobbler.net/dtd/xspf-lastfm"> <title></title> <creator>Last.fm</creator> <link rel="http://www.last.fm/skipsLeft">9999</link> <trackList> <track> <location>http://play.last.fm/user/23c7ece283ec1b838e9c512c3a6ce75b.mp3</location> <title>The More I See You</title> <id>12983386</id> <album>Caught in the Act</album> <creator>Michael Bublé</creator> <duration>227000</duration> <image>http://images.amazon.com/images/P/B000BFH2S2.01.MZZZZZZZ.jpg</image> <lastfm:trackauth>ebe21</lastfm:trackauth> <lastfm:albumId>2330692</lastfm:albumId> <lastfm:artistId>1259455</lastfm:artistId> <link rel="http://www.last.fm/artistpage">http://www.last.fm/music/Michael+Bubl%C3%A9</link> <link rel="http://www.last.fm/albumpage">http://www.last.fm/music/Michael+Bubl%C3%A9/Caught+in+the+Act</link> <link rel="http://www.last.fm/trackpage">http://www.last.fm/music/Michael+Bubl%C3%A9/_/The+More+I+See+You</link> <link rel="http://www.last.fm/buyTrackURL"></link> <link rel="http://www.last.fm/buyAlbumURL">http://www.last.fm/affiliate_sendto.php?link=catch&prod=2330692&rt=8&s=1</link> <link rel="http://www.last.fm/freeTrackURL"></link> </track> <track> <location>http://play.last.fm/user/817e6d9f1b5872e849f4a4e343f89aa8.mp3</location> <title>El aire de la calle</title> <id>8706431</id> <album>El sentimiento garrapatero que nos traen las flores</album> <creator>Los Delinqüentes</creator> <duration>183000</duration> <image>http://images.amazon.com/images/P/B00005NG8Z.01.MZZZZZZZ.jpg</image> <lastfm:trackauth>26d34</lastfm:trackauth> <lastfm:albumId>2319274</lastfm:albumId> <lastfm:artistId>1195863</lastfm:artistId> <link rel="http://www.last.fm/artistpage">http://www.last.fm/music/Los+Delinq%C3%BCentes</link> <link rel="http://www.last.fm/albumpage">http://www.last.fm/music/Los+Delinq%C3%BCentes/El+sentimiento+garrapatero+que+nos+traen+las+flores</link> <link rel="http://www.last.fm/trackpage">http://www.last.fm/music/Los+Delinq%C3%BCentes/_/El+aire+de+la+calle</link> <link rel="http://www.last.fm/buyTrackURL"></link> <link rel="http://www.last.fm/buyAlbumURL">http://www.last.fm/affiliate_sendto.php?link=catch&prod=2319274&rt=8&s=1</link> <link rel="http://www.last.fm/freeTrackURL"></link> </track> <track> <location>http://play.last.fm/user/c319aca7d18e6fb65ee39781c0c03b14.mp3</location> <title>What You Believe</title> <id>4426581</id> <album>These Times</album> <creator>Mike Stern</creator> <duration>406000</duration> <image>http://userserve-ak.last.fm/serve/174s/16120879.jpg</image> <lastfm:trackauth>ee6fb</lastfm:trackauth> <lastfm:albumId>2143454</lastfm:albumId> <lastfm:artistId>1015063</lastfm:artistId> <link rel="http://www.last.fm/artistpage">http://www.last.fm/music/Mike+Stern</link> <link rel="http://www.last.fm/albumpage">http://www.last.fm/music/Mike+Stern/These+Times</link> <link rel="http://www.last.fm/trackpage">http://www.last.fm/music/Mike+Stern/_/What+You+Believe</link> <link rel="http://www.last.fm/buyTrackURL"></link> <link rel="http://www.last.fm/buyAlbumURL">http://www.last.fm/affiliate_sendto.php?link=uapc&prod=2053336&s=1</link> <link rel="http://www.last.fm/freeTrackURL"></link> </track> <track> <location>http://play.last.fm/user/6d7bf1d92c7472c053b61548ba67589b.mp3</location> <title>Dream of Mirrors</title> <id>1003452</id> <album>Brave New World</album> <creator>Iron Maiden</creator> <duration>559000</duration> <image>http://userserve-ak.last.fm/serve/174s/13138105.jpg</image> <lastfm:trackauth>a26de</lastfm:trackauth> <lastfm:albumId>2025750</lastfm:albumId> <lastfm:artistId>1000107</lastfm:artistId> <link rel="http://www.last.fm/artistpage">http://www.last.fm/music/Iron+Maiden</link> <link rel="http://www.last.fm/albumpage">http://www.last.fm/music/Iron+Maiden/Brave+New+World</link> <link rel="http://www.last.fm/trackpage">http://www.last.fm/music/Iron+Maiden/_/Dream+of+Mirrors</link> <link rel="http://www.last.fm/buyTrackURL"></link> <link rel="http://www.last.fm/buyAlbumURL">http://www.last.fm/affiliate_sendto.php?link=uapc&prod=1929422&s=1</link> <link rel="http://www.last.fm/freeTrackURL"></link> </track> <track> <location>http://play.last.fm/user/db0399ea4fba42e854125e5979d5fdcf.mp3</location> <title>Enfermo (Full length Version)</title> <id>107712913</id> <album>No Gravity</album> <creator>Kiko Loureiro</creator> <duration>241000</duration> <image>http://userserve-ak.last.fm/serve/174s/16628103.jpg</image> <lastfm:trackauth>cbd8e</lastfm:trackauth> <lastfm:albumId>2198693</lastfm:albumId> <lastfm:artistId>10049221</lastfm:artistId> <link rel="http://www.last.fm/artistpage">http://www.last.fm/music/Kiko+Loureiro</link> <link rel="http://www.last.fm/albumpage">http://www.last.fm/music/Kiko+Loureiro/No+Gravity</link> <link rel="http://www.last.fm/trackpage">http://www.last.fm/music/Kiko+Loureiro/_/Enfermo+%28Full+length+Version%29</link> <link rel="http://www.last.fm/buyTrackURL"></link> <link rel="http://www.last.fm/buyAlbumURL">http://www.last.fm/affiliate_sendto.php?link=uapc&prod=2098896&s=1</link> <link rel="http://www.last.fm/freeTrackURL"></link> </track> </trackList> </playlist>" amarok: BEGIN: void MultiPlayableCapabilityImpl::slotNewTracks(const QList<Track>&) amarok: END__: void MultiPlayableCapabilityImpl::slotNewTracks(const QList<Track>&) - Took 0.00016s amarok: BEGIN: virtual void MultiPlayableCapabilityImpl::metadataChanged(Meta::TrackPtr) amarok: END__: virtual void MultiPlayableCapabilityImpl::metadataChanged(Meta::TrackPtr) - Took 0.0002s amarok: BEGIN: virtual void Amarok::OSD::metadataChanged(Meta::TrackPtr) amarok: BEGIN: void OSDWidget::show(const QString&, QImage) amarok: END__: void OSDWidget::show(const QString&, QImage) - Took 0.0024s amarok: END__: virtual void Amarok::OSD::metadataChanged(Meta::TrackPtr) - Took 0.055s amarok: BEGIN: virtual void Meta::Album::notifyObservers() const amarok: BEGIN: virtual void CurrentEngine::metadataChanged(Meta::AlbumPtr) amarok: END__: virtual void CurrentEngine::metadataChanged(Meta::AlbumPtr) - Took 0.0047s amarok: END__: virtual void Meta::Album::notifyObservers() const - Took 0.005s amarok: BEGIN: virtual void Meta::Artist::notifyObservers() const amarok: END__: virtual void Meta::Artist::notifyObservers() const - Took 7.6e-05s amarok: BEGIN: void CurrentTrack::dataUpdated(const QString&, const QHash<QString, QVariant>&) amarok: END__: void CurrentTrack::dataUpdated(const QString&, const QHash<QString, QVariant>&) - Took 0.001s amarok: BEGIN: virtual void CurrentTrack::constraintsEvent(Plasma::Constraints) amarok: placing album at X: 17 and Y: 9 amarok: END__: virtual void CurrentTrack::constraintsEvent(Plasma::Constraints) - Took 0.072s
Hm, this bug happens more often to me lately. Last time it happened I got this output: Object::disconnect: Unexpected null parameter ASSERT failure in Listing loaded Plasma engines: "List is empty (no engines loaded!?)", file /home/panzi/software/amarok/src/context/ContextView.cpp, line 99 KCrash: Application 'amarok' crashing... sock_file=/home/panzi/.kde/socket-panzi/kdeinit4__0 E: core-util.c: Assertion 'pa_close(fds[0]) == 0' failed at pulsecore/core-util.c:2107, function pa_close_pipe(). Aborting. Unable to start Dr. Konqi I use Fedora 10, KDE 4.2.2, Qt 4.5.0 and Amarok SVN revision 950860 (I think thats from yesterday; I update amarok almost daily).
In my case, I do not use pulseaudio... so it's just the plain alsa/xine/phonon setup. I'm using the latest xine 1.1.16.3 and the bug still remains... Maybe a phonon problem? I don't know...
(In reply to comment #83) > m_useGaplessPlayback = true Maybe it's something related to gapless playback? How can I disable gapless playback to test if it helps me?
I don't understand how this bug could be "fixed" and users keep sending bug reports, duplicate of this one. I can reproduce this problem all the time with last.fm. I sent the debug output and nobody seems to care... Thsi annoying bug is abandoned unless it hits hard some Amarok developer... which does not to seem the case... :\
@Daniel and Mathias, please read what Mark said in comment #81: "If any of you folks can pinpoint the remaining issues to a specific component (Amarok, Phonon, xine, the weather..), then please open a new report at the right place." Adding comments to a closed bug is absolutely *not* useful, so if you really can identify a specific component, open a new bug.
Mark Kretschmann decided to close this report although it is not a solved issue. Many users have this problem. And worst, new bug reports are being marked as duplicated of this one. Ok, I will open a new one, but I bet someone will mark it as duplicated of this one, I bet.
*** Bug 190594 has been marked as a duplicate of this bug. ***