Version: 2.3-GIT (using KDE 4.5.4) OS: Linux When the albums applet is enabled and a track with an empty album is played, the album applet displays all tracks with an empty album tag (which are a lot). This causes the GUI to freeze for several seconds. During the freeze amarok uses 100% CPU, mysqld none, so the freeze seems to be caused by the applet itself (filling a list/listview?) and not by an expensive sql query. When the albums applet is disabled, the GUI doesn't freeze. Reproducible: Always
btw, the freeze also happens when the albums applet is loaded, but not currently visible.
Are you really using 2.3-git?
Oops, we're already on git-2.4. But I am definitely on current master.
Thank you for the feedback. Confirmed there are a lot of tracks being listed, but it doesn't freeze the GUI here. Could be dependent on the amount of tracks and the speed of the computer/HD (I use a SSD).
amarok: BEGIN: void Albums::dataUpdated(const QString&, const Plasma::DataEngine::Data&) amarok: END__: void Albums::dataUpdated(const QString&, const Plasma::DataEngine::Data&) [DELAY Took (quite long) 39s] whenever amarok changes the track it uses very much CPU and freezes about 39 seconds, Version 2.3.90, KDE 4.5.95 (4.6 RC2), openSuSE Factory removing the Albums widget resolves the issue I do have a fast pc (AMD Phenom II X6 1090T Black Edition, 8GB RAM, /home and / on a SSD) callstack of a moment during the high CPU usage phase #0 TrackItem::metadataChanged (this=0x36bb6c0, track=...) at /usr/src/debug/amarok-2.4.0/src/context/applets/albums/TrackItem.cpp:73 #1 0x00007fffb92b5092 in TrackItem::setTrack (this=0x36bb6c0, trackPtr=<value optimized out>) at /usr/src/debug/amarok-2.4.0/src/context/applets/albums/TrackItem.cpp:47 #2 0x00007fffb92aa969 in Albums::dataUpdated (this=<value optimized out>, name=<value optimized out>, data=<value optimized out>) at /usr/src/debug/amarok-2.4.0/src/context/applets/albums/Albums.cpp:149 #3 0x00007fffb92abace in Albums::qt_metacall (this=0x1bbf510, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fffffffabf0) at /usr/src/debug/amarok-2.4.0/build/src/context/applets/albums/Albums.moc:84 #4 0x00007ffff6010e3f in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib64/libQtCore.so.4 #5 0x00007ffff0f4e007 in Plasma::DataContainer::dataUpdated(QString const&, QHash<QString, QVariant> const&) () from /usr/lib64/libplasma.so.3 #6 0x00007ffff0f4e9b0 in Plasma::DataContainer::checkForUpdate() () from /usr/lib64/libplasma.so.3 #7 0x00007ffff0f51a43 in Plasma::DataEngine::timerEvent(QTimerEvent*) () from /usr/lib64/libplasma.so.3 #8 0x00007ffff600f7e9 in QObject::event(QEvent*) () from /usr/lib64/libQtCore.so.4 #9 0x00007ffff53c7d44 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4 #10 0x00007ffff53d024a in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4 #11 0x00007ffff792b976 in KApplication::notify(QObject*, QEvent*) () from /usr/lib64/libkdeui.so.5 #12 0x00007ffff5ffbc3c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4 #13 0x00007ffff6029528 in ?? () from /usr/lib64/libQtCore.so.4 #14 0x00007ffff6026294 in ?? () from /usr/lib64/libQtCore.so.4 #15 0x00007fffee0edca3 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #16 0x00007fffee0ee480 in ?? () from /lib64/libglib-2.0.so.0 #17 0x00007fffee0ee720 in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #18 0x00007ffff602696f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #19 0x00007ffff546cd9e in ?? () from /usr/lib64/libQtGui.so.4 #20 0x00007ffff5ffb092 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #21 0x00007ffff5ffb2a5 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #22 0x00007ffff5fff6eb in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4 #23 0x000000000040960d in _start () HTH regards cobexer
I can confirm this behavior (Amarok 2.4.0): [...] amarok: BEGIN: virtual void Albums::init() amarok: BEGIN: void Albums::dataUpdated(const QString&, const QHash<QString, QVariant>&) amarok: END__: void Albums::dataUpdated(const QString&, const QHash<QString, QVariant>&) [DELAY Took (quite long) 38s] amarok: END__: virtual void Albums::init() [DELAY Took (quite long) 38s] [...] But the strange thing is that I also get a delay of 38-39 seconds. Coincidence?
Git commit 55873d1a9423ddc151879151f2c2a7ef4a46f619 by Sven Krohlas. Committed on 03/07/2011 at 23:28. Pushed by krohlas into branch 'master'. Don't let the album applet freeze Amarok for ages We tried to show ALL tracks from ALL artists, that do not belong to an album, if some track from the currently playing artist did not have an album set. Took about 50 seconds for me on track change... TODO: show all tracks from this artist that are not part of an album. BUG: 277021 BUG: 260810 FIXED-IN: 2.4.2 M +1 -0 ChangeLog M +5 -0 src/context/applets/albums/Albums.cpp http://commits.kde.org/amarok/55873d1a9423ddc151879151f2c2a7ef4a46f619