When the Amarok window is open showing media sources, playlist, and context (just current track), Amarok usage is ~16%, Xorg usage is ~7%, and Kwin usage is also ~7%. When the Amarok window is minimized to tray, Amarok usage is ~3%, Xorg ~1%, and Kwin also ~1%. When I close the playlist view, Amarok usage with window showing halves, dropping to ~8%. Closing the context view doesn't improve anything. Could this be due to the "pulsating" current track in the playlist? See bug 244896 for more details. Reproducible: Always Steps to Reproduce: 1. Play a song with the window showing and playlist indicating current track (by pulsating) 2. Watch Amarok, xorg and Kwin usage Actual Results: Resource usage is higher than it should be Expected Results: Amarok usage is around half, and xorg and kwin usage much lower as well. System: AMD 5800K (quad core, 3.8Ghz), Catalyst 13.11 beta 6 (compositing set to Opengl 3.1, raster).
Confirming due to multiple user reports (although I cannot reproduce such a high CPU load on my system).
Please attach a screenshot here showing your playlist. I'd like to see if your playlist layout might have any influence on performance. Also please list your compositing settings, from System Settings -> Desktop Effects -> Advanced (if you are using KWin).
Created attachment 83698 [details] Moult's amarok-playlist
Attached my playlist, The layout is Title \ Artist \ Moodbar - Playcount - Score - Rating Compositing settings: Compositing type: OpenGL 3.1. Qt graphics system: Raster. General options: keep window thumbnails: only for shown windows. Scale method: accurate. Suspend desktop effects for fullscreen windows is disabled. OpenGL options: Tearing prevention (VSync): Automatic. Enable color correction is disabled.
@Dion: So the main difference to my setup is that you are using the Moodbar, which is also getting rendered in playlist items. I wonder if this could be the culprit. @Michael D: Are you also using the Moodbar feature? Please attach a screenshot of your playlist here.
I'm not using the moodbar. My playlist layout is "verbose". I've attached a screenshot of it.
Created attachment 83727 [details] screenshot
I have the exact same issue when not minimized, and I was able to stop it by simply disabling the playlist view, but this is not very useful, as you can imagine. - On an nvidia driven system, it causes moderate to severe response lag - On an ATI driven system, it's not as bad provided radeon driver is used. On fglrx, it's *unusable* - On a fairly weak intel early sandybridge driven laptop, it's hardly noticeable. If my vote counts for anything, just kill the pulsating, it's a UX fail: Until I saw this bug suggesting the pulsating was a problem, I didn't even notice it pulsed, and moreover, it took me MINUTES to even find where the pulsating referenced here was occurring. I have been using KDE at home and work for at least 3 years (since Gnome3/Unity), and I play music the whole time - I never noticed it pulsed, but I always knew what track was playing.
An interesting pseudo-related bug categorized won't fix: https://bugs.kde.org/show_bug.cgi?id=123298 Might be nice to revisit this given the performance impact it has.
@liquid: Thanks for the information. Indeed it performs well with the Intel driver (which I used for development).
@mark on intel graphics, the CPU usage may not be noticeable, but it's still there. ~40%CPU when Amarok is open, and playlist is visible. Down to ~15 if I turn off the playlist view, and under 10% when minimized.
Any news on this. How can a bug like this be left unresolved for over half a year?
(In reply to comment #12) > Any news on this. How can a bug like this be left unresolved for over half a > year? You are very welcome to give a hand, as you seem to have more free time than we have...
I suppose there is an easy way (for a developer) to see whether the pulsating current track animation is causing the high cpu usage? Would be nice to have this fixed so that we can keep the window open without worrying about battery drain/cpu usage.
As mentioned in earlier comments this depends on the graphic driver, I can't reproduce this here with the Intel driver at all, nor can Mark. So no, it is not that easy for the main developer, as he doesn't have another driver at hand. This report was confirmed due to user reports, but as for the fix: if a developer with other graphic drivers could give a hand...
Would any debug info from affected users be useful to you?
(In reply to donniezazen from comment #16) > Would any debug info from affected users be useful to you? Yes, but only if you can also test new settings in the git version.
(In reply to Myriam Schweingruber from comment #17) > (In reply to donniezazen from comment #16) > > Would any debug info from affected users be useful to you? > > Yes, but only if you can also test new settings in the git version. Thanks Myriam. Let me try to spin the git version of Amarok on my Fedora box. I quite don't know how to do that but I will figure it out. What would you want once I am running the git version? Stack Traces[1]? [1] http://fedoraproject.org/wiki/StackTraces
(In reply to donniezazen from comment #18) > > Thanks Myriam. Let me try to spin the git version of Amarok on my Fedora > box. I quite don't know how to do that but I will figure it out. It is rather easy, you can just follow my blog about how to run Amarok's git version: http://blogs.fsfe.org/myriam/2009/09/26/compiling-amarok-from-git-locally-full-summary/ If you follow this step by step it will work without problems. Despite it's initial publication date in 2009, I kept it up-to-date. > > What would you want once I am running the git version? Stack Traces[1]? > > [1] http://fedoraproject.org/wiki/StackTraces Valgrind would be a better candidate, since we don't have a crash situation anyway. You can run it with this line: valgrind --log-file=amarok amarok Then play a sequence where the CPU consumption raises for a few minutes, then stop the playback and exit Amarok. Beware, running an application with Valgrind is extremely slow, so you will have to be patient.
I was successfully able to build Amarok from source using your guide but it crashes as soon as I press play. Here is the log https://gist.github.com/donniezazen/960886b4d1a12e56f4f0 Valgrind also seg faults. valgrind --log-file=amarok ./amarok Segmentation fault
(In reply to donniezazen from comment #20) > I was successfully able to build Amarok from source using your guide but it > crashes as soon as I press play. Here is the log > https://gist.github.com/donniezazen/960886b4d1a12e56f4f0 > > Valgrind also seg faults. > valgrind --log-file=amarok ./amarok > Segmentation fault We would need a crash report, in this case, but please file a separate report, as it is most likely not related to this bug.
Fwiw, the last log posted had this: amarok: symbol lookup error: /usr/lib64/kde4/amarok_data_engine_lyrics.so: undefined symbol: _ZN13ScriptManager17notifyFetchLyricsERK7QStringS2_ If you happen to have the distro-supplied amarok still installed, remove that one while testing a build from source (to be on the safe side).
*** Bug 344194 has been marked as a duplicate of this bug. ***
Hi, first, I can definitely reproduce this issue and pinpoint the currently playing item as the culprit. This is how to reproduce: Crete a playlist that is long enough so that you can scroll down the list. 1. => Start playing a track in Amarok with the currently playing track displayed and watch CPU usage. (For me, this is approx. 22% CPU usage on a Core-i7, no matter if using either the integrated intel-video unit or the nvidia GPU...) 2.=> Then, just scroll the playlist so that the currently playing track is not displayed any more, and watch how CPU usage drops to about half the original value. Yes, that is true, only by scrolling down the playlist, I can significantly save battery usage on my laptop computer.. I am willing to compile an updated Amarok version for testing, of course.
(In reply to Ulrich Lukas from comment #24) > Hi, > > > first, I can definitely reproduce this issue and pinpoint the currently > playing item as the culprit. ... Which version are you talking about? Remember, this bug is about the development branch, so you need to compile Amarok with the latest version. > > I am willing to compile an updated Amarok version for testing, of course. Yes, please do. We have a nice instruction for that (see comment #19). Also please always give your system information (distro, KDE version, Qt version, etc.) If you test with the git version, it is important to remove the distribution provided version. FWIW: running the latest git version v2.8.0-467-g1527da7 on Kubuntu 14.10, KDE 4.14.2, with an integrated Intel card (Lenovo X220), playlist of 235 tracks, no CPU spike visible, no flickering, nothing. CPU usage here (Core i7-2620M CPU @ 2.70GHz) stays at around 10%.
I did a git checkout of v2.8.0-467-g1527da7 just now. Using KDE 4.14.6 on Kubuntu 15.04, currently running nvidia-346 driver on a Lenovo T520. Window compositor is switched on in Systemsettings. CPU load as displayed via "top" goes from approx. 23% to 11% when scrolling the currentyl playing track out of the window boundaries.
I tested again after a fresh reboot with compositor disabled: no change. The "23% CPU load" I wrote before applies to "top" in "Irix mode", i.e. 23% of one core CPU time. I can test v2.8.0-467-g1527da7 again tomorrow with the integrated Intel graphics enabled only. But with the distribution v.2.8 Amarok I experienced the same behaviour before.
(In reply to Ulrich Lukas from comment #27) > I tested again after a fresh reboot with compositor disabled: no change. > The "23% CPU load" I wrote before applies to "top" in "Irix mode", i.e. 23% > of one core CPU time. > > I can test v2.8.0-467-g1527da7 again tomorrow with the integrated Intel > graphics enabled only. > But with the distribution v.2.8 Amarok I experienced the same behaviour > before. And you did remove the distribution package to make sure you are really running the git version? Please check the "About Amarok" dialog box. You also need to run this with a clear configuration, so you need to erase the amarok* files in $HOME/.kde/share/config/
Myriam Schweingruber wrote: > Please check the "About Amarok" dialog box. I did: Version 2.8-git Using KDE 4.14.6 (Build Date: Apr 29 2015) > And you did remove the distribution package to make sure you are really running the git version? > you need to erase the amarok* files in $HOME/.kde/share/config/ I did both things now. No difference. The effect (less CPU usage when track is not displayed on-screen) is more pronounced when the currently playing track is displayed with a big two-line entry (differing interpret or song not part of an album), and of course when switching on a resource-hungry graphical analyser. (But even then, it is noticeable) Also, using the integrated GPU on the Ivy-Bridge Intel CPU with xserver-xorg-video-intel, version 2:2.99.917-1~exp1ubuntu2build1 shows the same behaviour.
Thank you for the fast feedback. Funny I can't reproduce this at all, tested with verbose layouts as well.
Same problem here. Maybe the hardware is the key here? I'm using Intel Core 2 Duo E8400 on Gigabyte GA-EP35-DS3 motherboard, ATi Radeon HD3650 and 4GB of RAM. I'm using Arch Linux (x64), xf86-video-ati driver, most recent KDE (I had the same problem with KDE 4). I have OpenGL 3.1 with EGL enabled for compositor. With playlist visible the CPU usage jumps to ~20-30% on both cores, with window minimized it's less than 10%.
On my girlfriend's laptop (Lenovo B50 with Intel i3 processor and integrated Intel HD graphics) the problem can probably be seen, but with a lot smaller "scale". If the playlist is visible, amarok uses ~14% of CPU (reported by top). If the window is minimized, the usage drops to about half of that (6-7%). Because this CPU has 4 cores, this translates to around 3-5% for each core in first case and ~1-2% for each core in second case. The software configuration is identical (except the drivers <: ).
I've just removed amarok stable version, removed all configs (everything with *amarok* in name) that I could find in my home folder, compiled git version (package amarok-git from Arch's AUR, amarok-git-v2.8.0.468.g014a851-1) and the problem seems to be a bit smaller... With window minimized I get 5-10% on each CPU, with window visible it's ~10%. The funny thing is that I now removed the git version, removed the same config files and installed the stable version again... And the usage of CPU is identical to the git version (~5% with window minimized, ~10% with window visible). Anyway - the playlist is still to be blamed, because if I hide it (so current track is not highlighted) the usage with visible window drops to ~5%. When window is minimized, CPU usage doesn't change. Instead of hiding the playlist the problem can be confirmed in the way described above - create long playlist, scroll it to the position when currently playing track is not visible - CPU usage drops - scroll it back to see currently playing track - CPU usage rises.