Version: 1.4.5 (using KDE KDE 3.5.3) Installed from: SuSE RPMs Compiler: gcc 4.0.4 OS: Linux After upgrading to 1.4.5 i'm having random crashes with amarok. The program simply freezes, specially after unpausing it or on track change (in fact i only remember those 2 cases). So i compiled it with full debug enabled, and that's the end of the output (when happened one of those crashes, after unpausing): amarok: [Moodbar] Resetting moodbar: /home/mamonetti/mp3temp/Dimmu Borgir - In Sorte Diaboli/Dimmu Borgir - The Chosen Legacy.mp3 amarok: [ContextBrowser] [CUEFILE]: /home/mamonetti/mp3temp/Dimmu Borgir - In Sorte Diaboli/Dimmu Borgir - The Chosen Legacy.cue - Shoot blindly and missed, searching for other cue files. amarok: [ContextBrowser] [CUEFILE]: - Didn't find any matching cue file. amarok: BEGIN: virtual void Fader::run() amarok: BEGIN: virtual void ThreadManager::Thread::run() amarok: BEGIN: SqliteConnection::SqliteConnection(const SqliteConfig*) amarok: END__: SqliteConnection::SqliteConnection(const SqliteConfig*) - Took 0.00087s amarok: END__: void EngineSubject::newMetaDataNotify(const MetaBundle&, bool) - Took 0.28s amarok: END__: void EngineController::play(const MetaBundle&, uint) - Took 0.39s amarok: BEGIN: void CurrentTrackJob::showArtistsAlbums(const QString&, uint, uint) amarok: END__: void CurrentTrackJob::showArtistsAlbums(const QString&, uint, uint) - Took 0.39s amarok: END__: virtual void ThreadManager::Thread::run() - Took 0.85s amarok: [ThreadManager] Job completed: CurrentTrackJob. Jobs pending: 0 amarok: BEGIN: void EngineSubject::stateChangedNotify(Engine::State) amarok: BEGIN: virtual void ContextBrowser::engineStateChanged(Engine::State, Engine::State) amarok: END__: virtual void ContextBrowser::engineStateChanged(Engine::State, Engine::State) - Took 8.8e-05s amarok: END__: void EngineSubject::stateChangedNotify(Engine::State) - Took 0.2s amarok: [ThreadManager] Threads in pool: 2 amarok: [ThreadManager] Threads in pool: 2 amarok: [ThreadManager] Threads in pool: 2 amarok: [xine-engine] XINE_PARAM_EARLY_FINISHED_EVENT disabled amarok: BEGIN: void EngineController::play(const MetaBundle&, uint) amarok: [controller] Loading URL: file:///home/mamonetti/mp3temp/Dimmu%20Borgir%20-%20In%20Sorte%20Diaboli/Dimmu%20Borgir%20-%20The%20Serpentine%20Offering.mp3 amarok: BEGIN: virtual bool XineEngine::load(const KURL&, bool) amarok: [xine-engine] Before xine_open() ***** amarok: [xine-engine] After xine_open() ***** amarok: [xine-engine] XINE_PARAM_EARLY_FINISHED_EVENT disabled amarok: END__: virtual bool XineEngine::load(const KURL&, bool) - Took 0.014s amarok: BEGIN: virtual bool XineEngine::play(uint) amarok: [xine-engine] XINE_EVENT_UI_PLAYBACK_FINISHED I use xine engine using alsa as output. I have libxine1-1.1.4 and alsa 1.0.9 (i'm on opensuse 10.0 with kde 3.5.3). What happened this way was that the GUI became frozen, but the song that was being played was able to end. After this i was able to see the last event at the output (this one for XINE_EVENT_UI_PLAYBACK_FINISHED) but the program was not responding. In fact the keyboard stoped working while i didn't kill amarok completely. After having killed it the keyboard worked again. Regards
Can you try to reproduce with 1.4.6? Seems to be related to bug 142364.
I've been able to prevent the error by disabling both crossfading and OSD (with 1.4.5), but I'll enable them again for testing with 1.4.6 I'll post again when my tests have finished Regards
i've noticed the problem still up at 1.4.6 i've tried to split it, for testing separately crossfading and OSD. after some time only with OSD enabled it doesn't seem to crash, so i should think about crossfading as the main reason of the problem (anyway i'll disable OSD and re-enable crossfading in order to try to reproduce the error again) regards
well, only with crossfading enabled it didn't crash after all.. maybe something related to both them when enabled at the same time? or simply it's a different source for the problem? dunno the fact is that the problem appears randomly, it's not easy to reproduce :/ regards
As said in bug #142364 it's still there.. i've seen it again, and seems to be some kind of deadlock related to crossfading if i'm right it appears if you try to launch a track change (go next/previous) or (un)pause when you are inside crossfading time (anyway i'm pretty sure it's related to those pair of actions) regards
I'm not for sure, but I think I'm experiencing similar problems as you do... I placed my backtrace and system specs here: http://forums.gentoo.org/viewtopic-t-577440.html But the thing is, crossfading or fading in anyway doesn't make a difference within 2 to 10 numbers it freezes. The only way I can have it run longer is by starting it in GDB or with an strace. So I guess it's a timing issue but I could be totally wrong ofcourse... I do hope this thing gets solved since it's the only unstable APP I have and I've this problem for over half a year now through different Amarok versions and it's annoying.
Can you try upgrading to xine 1.1.7?
I can confirm it in 1.4.7 from kubuntu packages. xine & alsa. To reproduce: 1. Put some tracks into playlist 2. Set crosfading to couple of secconds (4 in my case) 3. Play a track till the end 4. Just when the track changes, pause 5. While on pause, change track
And OSD has nothing to do with it.
I can confirm it still at 1.4.8 with xine-lib 1.1.8. Simply use the sequence described by #8 and there it is: the track change has been done, so song3 is being played but the GUI has frozen and the title of the window is still showing song2 (song1 = initial song, song2 = song wich starts to play and song3 = next song that should be played when you hit the "next" button during crossfading).
Amarok 1.4.x is in bugfix-only mode as development is focused on Amarok 2. Unfortunately your bug will very likely not get fixed, as the risk of regressions is too high and the Amarok developers do not have the resources for it. Thank you for your report though. Please don't hesitate to report new bugs should you have any problems with Amarok 2 once it is released.
closing for reasons stated by Edward.