From john.maguire on April 24, 2010 09:11:53

I'm pretty sure this is the analyzer. Starting a song with the analyzer on and then
pausing has the same result as you, but turning off the analyzer and then playing and
pausing again yields 0% CPU.

Labels: Component-UI

From andrew.gaydenko on April 24, 2010 10:40:15

I have restarted the player - it's OK now. Probably I have tried to turn analizer on
and off- don't remember exactly (did not restarted since r773 ). Let's close the issue
for now. And I'll report at case will notice CPU eating again. Ok?

From biglouis87 on April 30, 2010 11:20:04

I also confirm the high cpu usage, but I think the analyzer is not the only cause of
the problem: turning it off decrease the cpu usage, but it remains higher than other
players (in my case it passed from 40% to 20% in foreground and from 20% to 10% in
tray, but it is not normal yet...)
I use Ubuntu 10.04 on Gnome, with a Core Duo T2400 @1,8GHz

From andrew.gaydenko on May 04, 2010 21:55:13

More long and thoughtful observation definitely shows the problem still exists:
sometimes the player eats 1-2%, and sometimes 20-25% of a core - during minutes. And
I have not found any reasons for such behaviour. Of course, I mean a situation when
collection dirs (in fact - the only dir at my case) don't change any way. And all
above is for the app being minimized in system tray.

From john.maguire on May 07, 2010 06:18:34

I made a change recently which should have improved this. Any luck?

From andrew.gaydenko on May 07, 2010 06:25:00

John,

Am rebuilding...
Which revision do you mean?

From andrew.gaydenko on May 07, 2010 06:37:17

r858 has the problem also. But it seems I have found possible reason: after app
starting I have waitedf or CPU eating and turned of app's trayicon - and got 0-1% of
CPU consumption. At any case I'm going to observe the behaviour during couple of
hours and will report.

From andrew.gaydenko on May 07, 2010 06:50:05

Sorry for noise. Idea wrt systray is wrong.

From andrew.gaydenko on May 21, 2010 07:32:42

Probably it will help to narrow the bug: eating can start after, say, 5 minutes after
player was started, as well as after 3-4 hours of using.

From andrew.gaydenko on May 26, 2010 01:00:48

As far as the bug is absolute showstopper preventing from everyday player use and,
thus, reducing feedback :-), I'm interested in ways helping to discover the problem
reason. I'm ready to follow developers' instructions at case such ones are possible.

From jkflying on May 26, 2010 14:56:02

I'm really liking what I've seen so far with Clementine (small download, not
cluttered with stupid features, etc.) but unless this CPU hogging bug gets fixed it
really is unusable. If it isn't minimized Clementine takes over 50% of the CPU on a
2.4GHz P4 the moment anything is playing. Even if all the analysers have been turned
off and Clementine has been restarted. Even when it is minimized there is still quite
a high CPU consumption...

Using 10.04 Lucid (Gnome)

From davidsansome on May 27, 2010 13:49:19

In r991 I've almost halved the CPU usage while the window is open by changing the
currently-playing-track animation in the playlist. Let me know if that helps you and
if so I'll try to optimise it more and/or add an option to disable it completely.

Also you might want to try compiling in release mode (cmake .. -
DCMAKE_BUILD_TYPE=Release) - that shaves off another couple of percent for me.

If you're getting high CPU consumption while the window is minimised then that's
something different... the only thing that's active when the window is hidden should be
the GStreamer playback bits. What kind of CPU usage are we talking about? Is it more
than other GStreamer-based players (try Rhythmbox)? If so, how much more? Can you
check you've got the Equalizer and ReplayGain turned off? Try choosing a different
GStreamer backend in the settings dialog - is it better with auto, alsa, oss or
pulseaudio? Is the CPU usage the same when you try different audio formats (eg, mp3,
ogg, flac)?

Try running this from the commandline, it's a similar pipeline to the one Clementine
uses, without the equaliser:

gst-launch uridecodebin uri=file:///path/to/some/music ! audioconvert ! audio/x-raw-
int,width=16,signed=true ! volume ! audioresample ! audioconvert ! autoaudiosink

Labels: -Priority-Medium Priority-High

From andrew.gaydenko on May 27, 2010 14:04:50

David,

Yes, CPU eating takes place when the app is hidden (tray icon is visible only) also.
And, as I have mentioned earlier, eating doesn't start just after app starting.

It is possible to have from few minutes to few (3-4) hours with "lucky" 1-2% CPU
usage. At some point the app starts to eat 20-25% of one CPU core (I have Core 2 Duo).

The problem isn't gstreamer related. Well, it may be. But I have not met the problem
with (sorry) Amarok 2 testing with gstreamer phonon backend in use.

I hate all kinds of Equalizers and ReplayGains :-) and such options are turned off.

I'll try 'gst-launch' tomorrow.

From davidsansome on May 27, 2010 16:00:39

Ok thanks.
I don't think it's gstreamer related either, I'm just wondering whether our equaliser
(or something else) might be doing something stupid even when it's turned off.

I'll try to reproduce the problem on a Kubuntu box tomorrow. If I can't then I'll get
you to have a play with a profiler :)

From andrew.gaydenko on May 28, 2010 03:24:32

Have tried 'gst-launch' with expected result - no problems.

From davidsansome on May 28, 2010 10:16:25

I was able to reproduce the problem here :)
Can you try r998 and see if it's fixed for you?

From andrew.gaydenko on May 28, 2010 10:22:47

Already have noticed and am building :-) As far as testing can take many hours
(because of sporadic eating start), I will not be too fast with reporting.

From andrew.gaydenko on May 28, 2010 11:05:48

David, sorry, already have got high CPU consumption :-(

From davidsansome on May 28, 2010 11:10:58

Bah! Ok, I'll keep looking...

From jkflying on May 29, 2010 01:27:24

I'm able to get rid of the high CPU consumption by disabling the 'glow' in the playlist.
I did this by copying the code from playlistview.cpp/StopGlowing() into
playlistview.cpp/StartGlowing(). I'm not sure if it's the same issue that
andrew.gaydenko is experiencing.

Oh, and I think you may have introduced a new bug by caching the text: if you edit
the tags in the track that is currently playing they don't visibly update in the
playlist until the next song starts playing.

From andrew.gaydenko on May 29, 2010 02:06:28

To check jkflying's way have started testing with empty StartGlowing() method body.

P.S. BTW, my eyes are very happy with eliminating additional unneeded visual effect :-)

From andrew.gaydenko on May 29, 2010 02:39:45

No, empty StartGlowing() doesn't help.

jkflying, are you sure the problem is indeed eliminated for you? The thing is, for me
CPU eating can start after few hours of normal (1-2% of CPU) working.

From jkflying on May 29, 2010 03:58:39

I think we have different issues. Mine would start the moment the 'pulsing' of the
currently playing song starts. I have left Clementine playing for many hours now and
have yet to see your problem. I'm on a single core though, no hyperthreading. Perhaps
it is a concurrency issue with the dual cores?

From jkflying on May 29, 2010 04:00:16

Another issue with the caching: if the columns are resized the currently playing line
does not resize.

From davidsansome on May 29, 2010 10:21:06

I have 8 cores and I don't get the problem :p
I'll have a go at fixing the caching and optimising the glow some more.

Andrew: I've left it playing for 24 hours now and I'm still on 1-2% usage. Could you
see if you can do some debugging for me?
Run clementine under gdb:
gdb ./clementine
run

Then leave it playing until you see the high CPU usage. Press Ctrl+C, and type:
info threads
You should see a line for each thread, most of them should be in either "poll" or
"pthread_cond_wait". If you see one that isn't, select it using the number in the
left column and get a backtrace:
thread
bt

If all the threads are in poll or pthread_cond_wait then you just happened to stop it
during the 50% that wasn't using your CPU - type "cont", wait a couple of seconds then
Ctrl+C and do it again.

Hopefully the backtrace will give me some idea what's causing the problem!

From jkflying on May 30, 2010 00:19:06

Hang on. I think I've seen it. Even when paused, Clementine will take about 10% of
the CPU. Sometimes pausing/playing fixes it, sometimes just making Clementine the
current window fixes it, sometimes not though. I'll try doing a gdb.

From andrew.gaydenko on May 30, 2010 00:47:48

jkflying, all symptoms your have decribed fit my case also.

David, I never use the app just in playing mode. Most common way - create playlist
with 1-5 albums, minimize and LIRCing (pause toggling, volume tuning).

The app is in debug mode now, and I have catched 6-7 eatings, but at all cases only
poll and pthread_cond_wait threads were listed. And "current eating period" ends
after 1-3 'cont's. Am waiting for next one :-)

From andrew.gaydenko on May 30, 2010 05:58:45

David, I have another Ctrl-C cases - all with the samed result (poll and
pthread_cond_wait only). Are there another ways to narrow the problem?

From davidsansome on May 31, 2010 15:27:50

Right, I have some more things for you to try:

1. Try running clementine in strace:
   strace ./clementine
   It will produce loads of output, so best to redirect it to a file:
   strace ./clementine > strace.out
   If you kill Clementine with Ctrl+C as soon as you see it start to use CPU then the
   useful bits will be at the bottom of the file. Upload it here and I'll have a
   look.

2. Try to find the exact revision where this problem began. GStreamer support came
   in revision 586 , so start from there:
   svn up - r586 Then maybe go up in 50s or so until you notice the high CPU usage again. Then
   go back and try to narrow it down to a specific revision.

3. If nothing else works then I'll litter the code with debugging output, so we can
   see if anything's being called more than it should.

From jkflying on June 01, 2010 07:45:59

My gdb is giving funny results so I changed some of the cmake options using -i to
show pthread_cond_wait or poll, (main think I think was taking -DNDEBUG out of the
compile options) but 'info threads' still just shows lines like:
6 Thread 0xb5613b70 (LWP 8185) 0x0012d422 in __kernel_vsyscall ()
(all end in __kernel_vsyscall () )

The funny thing is, I can't reproduce the bug now. I've been trying for several
hours, whereas before I could get it the moment I switched a track by double-clicking
then skipped forward.

Any clues?

From davidsansome on June 27, 2010 06:32:22

Ok cool take your time :)

From andrew.gaydenko on June 27, 2010 15:57:36

David,

Reproting: I'am able to reproduce the issue with r1366 - r1377 . Last hour am testing r1378 without any success, taking in mind "success" meaning here: it is the issue reproduction :-)

I'm going to continue current r1378 session, but at case you have some reason to stop the session - I'm ready also.

From andrew.gaydenko on June 27, 2010 17:51:19

I surrender to reproduce high CPU usage with r1378 - additional two hours didn't help :-)

From himynameiszacHandiamapirate on June 27, 2010 20:41:37

fingers crossed

From himynameiszacHandiamapirate on June 28, 2010 21:49:33

Oh dear, is .4 being released before figuring this one out? I feel like you guys may have finally hit on the source of the problem, and high cpu usage is going to be a real stickler for some people (not to belittle any of the crazy super excellent changes that have been made since .3)...

From davidsansome on June 29, 2010 11:50:53

Yeah sorry about that, I've pushed back 0.4 enough already, and this fix will need a bit of testing to make sure it doesn't break crossfading I think.

Andrew - I'll try to do a fix soon and get you to test it :)

From andrew.gaydenko on June 29, 2010 20:54:50

David, yes, I'm on-line for testing. Have you some hook now?

Himynameiszac Handiamapirate, I think we can be slightly more kind to developers :-) I mean, all those accompanying tasks such releasing (for plenty of platforms!), announcing here and there, and there... and so on - all these tasks demand developers' time, preventing them to apply their efforts to more interesting for them and valueable for us - users - activity - writing a code itself ;-)

From himynameiszacHandiamapirate on June 29, 2010 21:08:32

Was I unkind in any way? Do I really come off as though I do not grasp these basic concepts? Sheesh.

From himynameiszacHandiamapirate on June 29, 2010 21:10:57

Or is the internet really completely cutting me off from understanding that you made a joke just now? My head is spinning...

From andrew.gaydenko on June 29, 2010 21:50:00

I mean at a moment when most 0.4 release related work is done, it isn't efficient (wrt developers' efforts) to postpone a release (and redo some work later) when new information about some (yes, popular, but with limited audience) bug has appeared - at situation when both fixing and testing (with yet not predictable results) demand efforts also.

Yes, it is a joke. Any joke is partly a joke, isn't it? :-) No complain, just humble opinion.

From himynameiszacHandiamapirate on June 29, 2010 22:11:05

The bug doesn't even affect me, but I do think it's an important one to address. I was just sticking up for the fact that you've been talking about it for two months. Oh well.

From davidsansome on June 30, 2010 13:41:30

Could you switch back to trunk and try r1394 ? I've fixed what I think was causing the problem. Keep those fingers crossed!

From himynameiszacHandiamapirate on June 30, 2010 13:53:13

It's been very hard to type, in the meantime... :P

From andrew.gaydenko on June 30, 2010 14:03:20

David, sorry, we are still not lucky. A little change is: instead of 20-25% I see 17-20% now.

From davidsansome on June 30, 2010 15:20:21

Damn! Ok, it must not have been what I thought it was, so I've split up the change that fixed it before into a load more little changes for you to try. Switch back to the gstreamer-light branch and try r1396 to r1402 .

This is the weirdest bug I've ever seen :S

From andrew.gaydenko on June 30, 2010 17:05:21

r1396 usage is 25-26% (even slightly higher). r1397 - during an hour can not reproduce the issue. Continueing...

Keep your fingers relaxed - don't provoke high CPU usage! ;-)

From andrew.gaydenko on June 30, 2010 17:32:21

r1397 is also affected. Continue with next revisions.

From andrew.gaydenko on June 30, 2010 21:04:47

David,

It seems like all is OK with gstreamer globally :-) I was able to reproduce high CPU usage with all r1396 - r1402 revisions. Probably, I just wasn't lucky with reproducing the issue during previous series of testing - you see, I still don't see any reproducable steps set, and even at multi-hours testings it is rather difficult to say "yes, this revision is OK".

OK. With two last revisions ( r1401 , r1402 ) I tried another way to reproduce the issue rather my common way (last one is a navigating via systray icon context menu). I have catch the issue with just double-clicking on the playlist items and for both revision has got the same behaviour: when high CPU usage "starts", it is ~15-18%. If at this point I hide the app main window by clicking on systray icon, usage rises up to 25%. Next main window unhiding "cured" the situation at both cases (~4%).

So, it seems like some relation with UI does exist. Probably, we can test this way: remove (one by one) few controls - scope, seek slider, volume slider, current track blinking, and I'll test all these variants - this time starting from "most empty" one :-)

From davidsansome on July 01, 2010 12:35:05

Just an idea, but I hadn't completely done all the changes in r1402 . Try r1409 in the branch - this should be identical to r1378 that possibly fixed the problem before.
I don't want to start on another road before we're completely sure that this wasn't the problem :)

From andrew.gaydenko on July 01, 2010 18:34:48

David,

I wasn't aware r1402 still has something undeleted in comparison with previous series' "good" case.

During last four hours I can not reproduce the issue with r1409 . Probably, we must not be too fast, and there is a sense to test the branch more. To make testing more smooth it would be handy for me to have volume regulating in hand. Is it possible to return the regulating, keeping app's state intact from other points of view? If it possible, I would test timerless barnch day or two to be more sure.

What do you think? Of course, I'm ready to follow any other scenario you will suggest.

From davidsansome on July 02, 2010 12:24:30

I left that change in there because I thought it couldn't possibly have that kind of effect on the CPU usage - the timer was doing absolutely nothing! Obviously I was wrong :)
Try r1401 in trunk. The timer's still there (it has to be for crossfading and the analyzer to work), but it runs much less frequently now.

From davidsansome on July 02, 2010 12:25:11

Err sorry, r1410 not r1401

From andrew.gaydenko on July 02, 2010 13:03:38

He-he... Indeed, crossfading and analyzer are malefic features ;-)

OK, I'm testing trunk/ r1410 .

From andrew.gaydenko on July 04, 2010 00:15:29

All these hours (except sleeping) I can not reproduce the issue with r1410 . If other affected users have not other opinion, I would close the issue as fixed.

From davidsansome on July 04, 2010 03:38:44

That's great :) Thanks again for taking the time to test this, I'm glad we finally managed to find a solution!
I'm still not sure what was actually going wrong - just having an empty timer running shouldn't cause this kind of CPU usage. shrug

Status: Fixed

From nicholasdrouin on September 03, 2013 16:06:08

found: Its the mood bar. I have several hundred 2 hour tracks and it is trying to get the mood for each. Disable that and BAM 30% cpu down to 2-6 %

From elib6565 on September 18, 2013 16:17:19

Sorry to be the SECOND person to highjack a dead thread, but I had the same problem, and I verify that turning off mood bar and turning off analyzer get the application down to 8 to 10 % from 74% plus. Using a 6 year old (and low spec) system, so this is what I must deal with when using feature advanced apps. Wanted to be sure others knew.