Every time I running amarok it hangs for a minute or so and freezes entire KDE. Even though the KDE interface remains responsive I can't open any KDE application (e.g. dolphin), can't open email in kmail and can't even click a lick in already opened email message (can click of course but it does not open in a web browser until amarok becomes alive). During that time I see this in htop: — amarok —— ffmpeg (zombie) Even after it returns to live it only show up in system tray after I start to play something from the playlist. Reproducible: Always Steps to Reproduce: 1. Log in to KDE 2. Run Amarok Actual Results: Player hangs for a few minutes and block something in KDE which breaks other applications also and makes them freeze. I already had this bug before and it disappeared after some time (month or so) without my intrusions. Priority is set to major because it break entire KDE. Please change if that is incorrect.
Created attachment 80957 [details] Amarok debug output Please look at the line 888, seems like the issue is there.
Created attachment 80958 [details] Current track widget broken This is the reason. You can see the widget is not initialized properly and amarok run instantly after I removed this widget.
Please start Amarok from the console like this: amarok --debug --nofork Then attach the resulting debugging log here.
Hmm, I can't reproduce any more, even with "Current track" widget enabled. The widget is still broken, but amarok does not freeze any more. Will reopen this bug if it will happen again. Btw, I also re-indexed the collection, perhaps this also fixed something.
Reopening, as I saw something interesting in the debug log: amarok: BEGIN: void RecentlyPlayedListWidget::setupTracksData() amarok: BEGIN: void RecentlyPlayedListWidget::updateWidget() [heaven@arch: ~$] amarok: END__: void RecentlyPlayedListWidget::updateWidget() [DELAY Took (quite long) 50s] amarok: END__: void RecentlyPlayedListWidget::setupTracksData() [DELAY Took (quite long) 50s]
Possibly related to 322285.
Created attachment 81267 [details] Traces and output from Qt Creator repro Let me throw some data here. I can reproduce exactly what Alexander was experiencing, that is freezing of seemingly whole KDE, but it's kind of a roundabout repro. 1. Start Qt Creator with Amarok project; relevant cmake settings: CMAKE_BUILD_TYPE=debugfull CMAKE_C_COMPILER=clang CMAKE_CXX_COMPILER=clang++ CMAKE_CXX_FLAGS=-ggdb CMAKE_C_FLAGS=-ggdb 2. Run debugging through Qt Creator. The startup freezes on amarok: [MySqlStorage] Initialized thread, count== 4 (snipped of the output and the stacktrace during freeze are in the attachment) 3. After it eventually starts, quit Amarok. Every subsequent Amarok startup (normal, not through Qt Creator) will then hang on: amarok: BEGIN: App::App() amarok: BEGIN: void App::continueInit() amarok: BEGIN: EngineController::EngineController() and other KDE apps generally go unresponsive as well. Stacktrace in the attachment. What's different with starting through Qt Creator is that I use blank environment; the only environment variables set are DISPLAY, HOME, KDEDIR and KDEDIRS.
(In reply to comment #6) > Possibly related to 322285. Those are definitely related, but in any case: it is not an Amarok bug, as Konrad's tests show, something is amiss with a deeper layer, maybe dBus or Solid or Qt? Reminds me of the delay experienced in KMix, as reported by Christian Esken in this thread: http://lists.kde.org/?l=kde-multimedia&m=137353400511241&w=2 I suggest the developers take this to the amarok-devel list, with copies to the people in the multimedia thread. Changing status to NEEDSINFO, but UPSTREAM. Now to identify which UPSTREAM is the trick...
Sometimes I experiencing the same behavior with google chrome. It has a bug and does not kill all its processes during the exit. So almost every time I close google chrome I see some leftover processes in htop. A bit later KDE becomes unstable, for example right click on plasma desktop could take up to 30-40 seconds before I could see the menu, all other symptoms are very similar to these with amarok. Everything get back to life once those processes killed manually, same as with amarok. So it feels like there is a bug somewhere in KDE/its components which allow applications to freeze the whole desktop.
Alexander, it could be caused by a kded module not doing its D-Bus handling asynchronously. If you can reproduce this, please try disabling kded modules as explained at http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/ If the lockups are indeed caused by a kded module, please report back which one you had to disable.
*** Bug 322746 has been marked as a duplicate of this bug. ***
Closing correctly.