Bug 143420 - 1.4.5 freeze after pause
Summary: 1.4.5 freeze after pause
Status: RESOLVED INTENTIONAL
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: 1.4.5
Platform: openSUSE Linux
: NOR crash
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-24 11:48 UTC by Mamonetti
Modified: 2008-07-03 12:55 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mamonetti 2007-03-24 11:48:42 UTC
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
Comment 1 Kevin Funk 2007-06-23 19:15:25 UTC
Can you try to reproduce with 1.4.6? Seems to be related to bug 142364.
Comment 2 Mamonetti 2007-06-23 19:44:47 UTC
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
Comment 3 Mamonetti 2007-06-29 00:13:01 UTC
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
Comment 4 Mamonetti 2007-07-05 23:27:16 UTC
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
Comment 5 Mamonetti 2007-08-07 23:29:26 UTC
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
Comment 6 Cor Cornelisse 2007-08-22 16:57:35 UTC
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.
Comment 7 Jeff Mitchell 2007-08-23 22:56:16 UTC
Can you try upgrading to xine 1.1.7?
Comment 8 karaluh 2007-09-05 20:48:56 UTC
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
Comment 9 karaluh 2007-09-05 20:58:26 UTC
And OSD has nothing to do with it.
Comment 10 Mamonetti 2007-12-24 15:28:49 UTC
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).



Comment 11 Edward Hades 2008-06-15 21:24:37 UTC
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.
Comment 12 Seb Ruiz 2008-07-03 12:55:29 UTC
closing for reasons stated by Edward.