Version: (using Devel) Installed from: Compiled sources Top causes for wakeups: 19,5% (209,2) <kernel IPI> : Rescheduling interrupts 16,8% (180,2) juk : schedule_timeout (process_timeout) 12,7% (136,9) <interrupt> : uhci_hcd:usb4, ehci_hcd:usb8, wifi0 9,0% ( 96,2) npviewer.bin : schedule_timeout (process_timeout) 7,7% ( 83,1) knotify4 : schedule_timeout (process_timeout) 6,6% ( 71,0) <interrupt> : uhci_hcd:usb1, libata, nvidia 5,9% ( 63,4) USB device 8-4.4 : USB Optical Mouse (Logitech) 4,6% ( 49,0) npviewer.bin : futex_wait (hrtimer_wakeup) JUK is not playing , just resting in the systray and waking up the cpu very often ! (Programm : PowerTop)
This is likely caused by the polling to save covers and playlists. I've already fixed that for covers by making it only occur after a change, I need to do the same for playlists and this should be fixed.
I've committed a fix to trunk that causes playlists to save only after changes (although JuK right now seems to be over-conservative as to what is a change, it is not a timed event anymore). However the event happened every 10 minutes before so I think there's still more going on than just that.
The "over-conservative" event I was thinking about is the history playlist (every song you play changes the history playlist after a couple of seconds -> induces auto-save). This won't be a big deal since you'll only have this issue during active playback, therefore I consider the bug fixed. It will be available with KDE 4.2.
Git commit 62561ad031a2c1c03f9abc266c621d83e48f6b8b by Michael Pyne. Committed on 21/03/2021 at 18:19. Pushed by mpyne into branch 'master'. systemtray: Cleanups and modernization. Also a timer bugfix. The bug: When using the track popup announcement, a timer kicks off to tell the popup to fade out. A second timer is used to incrementally fade the popup a bit every few milliseconds until the popup can finally be hidden. However the first timer was never stopped, and would kick off the fadeout sequence again, over and over, only hidden to view since the popup is no longer visible. This might be related to the old bug 165899 (which I tried to fix a different way). I believe this happened in the Qt3/4 transition since the code seems to assume the first timer was a "single shot" timer, but it could have been wrong forever. M +80 -84 systemtray.cpp M +12 -14 systemtray.h https://invent.kde.org/multimedia/juk/commit/62561ad031a2c1c03f9abc266c621d83e48f6b8b
Git commit b64b37616f0490f60526defaf5335c4731dd41b4 by Michael Pyne. Committed on 25/03/2021 at 01:29. Pushed by mpyne into branch 'release/21.04'. systemtray: Cleanups and modernization. Also a timer bugfix. The bug: When using the track popup announcement, a timer kicks off to tell the popup to fade out. A second timer is used to incrementally fade the popup a bit every few milliseconds until the popup can finally be hidden. However the first timer was never stopped, and would kick off the fadeout sequence again, over and over, only hidden to view since the popup is no longer visible. This might be related to the old bug 165899 (which I tried to fix a different way). I believe this happened in the Qt3/4 transition since the code seems to assume the first timer was a "single shot" timer, but it could have been wrong forever. (cherry picked from commit 62561ad031a2c1c03f9abc266c621d83e48f6b8b) M +80 -84 systemtray.cpp M +12 -14 systemtray.h https://invent.kde.org/multimedia/juk/commit/b64b37616f0490f60526defaf5335c4731dd41b4