Bug 165899 - juk take to much CPU / Power when IDLE
Summary: juk take to much CPU / Power when IDLE
Status: RESOLVED FIXED
Alias: None
Product: juk
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Michael Pyne
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-06 23:48 UTC by christian
Modified: 2021-03-25 01:50 UTC (History)
0 users

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 christian 2008-07-06 23:48:22 UTC
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)
Comment 1 Michael Pyne 2008-08-13 01:07:30 UTC
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.
Comment 2 Michael Pyne 2008-08-27 05:22:10 UTC
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.
Comment 3 Michael Pyne 2009-01-02 21:36:27 UTC
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.
Comment 4 Michael Pyne 2021-03-21 19:16:39 UTC
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
Comment 5 Michael Pyne 2021-03-25 01:50:10 UTC
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