Panflute

Applet uses more and more CPU over time

Bug #531102 reported by Paul Kuliniewicz
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Panflute
Fix Released
Low
Paul Kuliniewicz
0.6
Fix Released
Low
Paul Kuliniewicz
Panflute 0.6.2

Bug Description

[taken from this comment (https://bugs.launchpad.net/panflute/+bug/476500/comments/15) on an unrelated bug:]

Running panflute 0.6.1 with Rhythmbox on Ubuntu 9.10 gives me the same problem. Namely, after having the applet running for a while (around 12 hours or so), it takes longer and longer for the track information to update (as much as 30s). During this time, the applet is unresponsive -- right clicking on it doesn't draw the menu until the information updates and my cpu usage goes very high. If I remove panflute from my bar and then re-add it, everything is fine again.

For reference, here are the contents of applet.stderr:

/usr/lib/gnome-applets/panflute-applet:111: Warning: g_set_prgname() called multiple times
  applet_factory)
/usr/lib/pymodules/python2.6/panflute/applet/widget.py:309: DeprecationWarning: PyArray_FromDimsAndDataAndDescr: use PyArray_NewFromDescr.
  pixels = pixbuf.get_pixels_array ()
/usr/lib/pymodules/python2.6/panflute/applet/widget.py:861: DeprecationWarning: PyArray_FromDimsAndDataAndDescr: use PyArray_NewFromDescr.
  for row in pixbuf.get_pixels_array ():

(the other two stderr.* files are empty)

What's interesting is that I used to use this back when it was called Music Applet, and I recall a similar thing happening.

See original description
Revision history for this message
Paul Kuliniewicz (kuliniew) wrote :

I've noticed this too, but haven't been able to figure out the cause so far. The CPU usage drops while paused, which rules out a problem with the metadata scroller as the actual cause. The fact that it exhibits slowdown is most likely because something *else* is using more and more CPU and taking time away from it.

My best guess is some timeout handler that isn't getting properly freed, but I currently have no idea where it is, and the fact that this problem only occurs over time makes it a bit tricky to debug.

description: updated
description: updated
Changed in panflute:
status: New → Confirmed
importance: Undecided → Low
assignee: nobody → Paul Kuliniewicz (kuliniew)
Revision history for this message
Paul Kuliniewicz (kuliniew) wrote :

After some testing, I've ruled out the idea of a runaway timeout or idle handler. I tried adding debug statements every time such a handler is invoked or returns, and don't see any extra calls being made.

I have noticed that stutters in scrolling seem to happen when the time ticks forward, suggesting the thing using too much CPU time gets called when handling a PositionChange signal. Since CPU usage drops to a normal level when the applet is closed, the problem is in the applet, not the daemon process.

That said, I don't have any guesses what happens in the update-current-time code path that causes the increasing levels of CPU, or why there'd be some sort of cumulative effect over time. I'll need to dig deeper in that part of the code, but at least now I'm fairly confident of what part of the code is the problem.

Paul Kuliniewicz (kuliniew)
Changed in panflute:
status: Confirmed → Fix Released
Revision history for this message
noper2 (dan-ginsberg) wrote :

Newest version fixed this for me too, so far. Thanks!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.