[raspberry pi] high cpu usage when idle with xbmc gui

[s7mx1]

Running latest openelec build as of yesterday and noticed that when xbmc sits idle the cpu usage goes up over 90% as reported by top.

There are similar issues reported on xbmc trac system: http://trac.xbmc.org/ticket/12888 http://trac.xbmc.org/ticket/12614.

CPU usage drops during h264 video playback up to 720p.

[steaky]

Hi,
I think this is due to the way that XBMC is coded - it redraws the entire menu every frame.
There is a setting somewhere enabling "dirty regions" - that is XBMC only redraws the part of the screen that has changed. But I remember reading somewhere that it was disabled for the raspi for some reason.
Steaky

[s7mx1]

I have enabled dirty region mode 3 which seems to reduced the load to around 30%.

[steeleyjim]

Recommended settings to improve GUI for other users experiencing this issue.

Create an advancedsettings.xml within your userdata dir with the following content:

http://www.xbmclogs.com/show.php?id=2706

[sraue]

@s7mx1 you have still the same problems with our latest builds from http://sources.openelec.tv/tmp/image/openelec-rpi/ ?

[huceke]

Thats by design and no bug.

[jamesblackburn]

[quote]
Thats by design and no bug.
[/quote]

How can 30-90% idle cpu be "by design"? Surely when idling xmbc usage should be negligible or devices which support power save will never enter low-power states, etc. Apart from anything else it reduces CPU available to other processes.

[huceke]

The main render loop is limited to 100fps/s. On a fast machine you reach this limit and xbmc starts to idle on rendering.
On a slow machine you can't reach this limit and see a high CPU usage. When we limit the render loop to lets say 20fps/s you would complain that XBMC's CPU usage is low but only get 20fsp/s. Ergo, this is by design.

[s7mx1]

The thing is if I disable RSS the idle load will go down to around 15% - 20%.

[jamesblackburn]

I have no issue with the renderer doing work when it needs to. The problem I see is that it burns CPU when nothing is changing on the screen. i.e. even sat in the idle state at the menus, with no video running, (and the screen dimmed), the rasppi cpu is pegged.

Surely if there's nothing to render the render loop should mostly be sleeping?

[huceke]

Unless the rendering logic in master isn't changed, it will stay like that.

[jamesblackburn]

I'm not saying you should necessarily be the one to fix it, but presumably it is fixable to some degree. As this is a real issue for raspberry pi owners, can this bug remain open (even if you're not actively looking at fixing it atm)? It bothers me a fair bit, so if no one else gets to it first I'll hopefully get a chance to dig into the code -- any insights you could given would of course be appreciated.

[vincebusam]

I see this too on my RPi, devel-20120704203304-r11493. Turning off the RSS crawl drops it from 80% to 20% CPU usage. Then, I see that it's doing an ioctl() on /dev/vchiq, attempting two non-blocking reads (socket and inotify), and checking the time in a busy loop. Couldn't this be put in a select/poll loop? I'll dig into this.

[vincebusam]

Looks like this polling loop is pretty fundamental to the design of xbmc. Switching to a fully blocking model sure would save a lot of electricity...

[jonacaz]

On my RPi, turning off RSS crawl also reduces CPU usage from 80% to 20%. Power consumption measured at wall socket drops from 4.3 watts to 3 watts. It's still a lot for a device left on 24 hours a day (and far higher than a phone running android but that might not be a fair comparison). When RPi is shut down consumption drops to 1 watt.

[nj314]

Can confirm that this bug is still present in the build from November 29 2012. On a fresh install, going to settings and turning off the RSS ticker does NOT reduce the CPU usage below 90% on my Pi. Am I missing something here?

Also, the link to advancedsettings.xml posted by steeleyjim is broken. Anyone know what was in that file?

[scharissis]

I can confirm this behaviour.

I've just done a fresh install of "OpenELEC-RPi.arm-2.95.4"/XBMC-12.0-BETA3 on a 1GB generic/unknown class on a RPi model B.

CPU usage was 98-100% and after turning off RSS it is now ~91-96% after 2 hours of being idle.

[mpilone]

I'm seeing the same issue with OpenELEC-Fusion.x86_64-2.95.4 (i.e. beta 4). I can't confirm that it was better with OpenElec beta3 but I never noticed it.

I found that changing the dirty regions algorithm to 1 drops the CPU back down to 2-5% and doesn't leave any noticeable artifacts with my hardware. My advancedsettings.xml looks like:

<advancedsettings>
  <gui>    
    <algorithmdirtyregions>1</algorithmdirtyregions>
  </gui>
</advancedsettings>

[scharissis]

@mpilone:
I tried that and not only did the CPU usage remain unchanged at ~95%, but it had huge, un-usable, artifacts. :(

[mpilone]

I think the advancedsettings.xml may have been a red herring for me. After some more digging I think I tracked the issue down to scripts.common.plugin.cache which gets installed as a dependency of some other add-ons, namely Youtube. You can see my post about it here: http://forum.xbmc.org/showthread.php?tid=116496&page=6

If my conclusion is correct, I think the advancedsettings.xml looked like it worked because I made the change and then restarted the xbmc process which at the same time resolved the timing issue with scripts.common.plugin.cache; however after rebooting the CPU usage returned even with the updated advancedsettings.

If you have scripts.common.plugin.cache installed try uninstalling it or disabling it to see if that helps at all. Unfortunately there seems to be a number of causes for high CPU ranging from HW issues to add-on bugs.

-mike

[odearing]

I'm new to Raspberry Pi (got one last Tuesday) and it's pretty much my first experience of Linux. I have OpenELEC installed, the lastest version, I think.
I was concerned about the high CPU usage. I found, as you guys have, that checking the CPU usage through Settings-->System Info shows it's about 91-94%. Turning off the RSS feed made no difference.

BUT, I found you can check the CPU usage through an SSH/Putty session using the "top" command. This shows CPU usage as only 15-20% when XBMC is on the main screen and idle, but jumps to over 90% when looking at Settings-->System.

Perhaps, ironically, just looking at the CPU usage in XBMC makes the CPU usage jump up!

Owen