[allan87]

The Pi is noticeably hotter when under a load. If I quit out of XBMC, the power supply and Pi are materially cooler. I assume this is because the CPU, at idle (on the home screen with nothing happening) runs at about 30%. It would be ideal if the Pi were built to sleep, but it isn't.

Not sure how practicable this is, but what if CEC were used to trigger either:
- XBMC quitting and restarting as needed; or
- display related processes being shut down/reactivated. Certainly, the processor does not need to be redrawing the screen when the Pi not being used.

Note: theoretically one could power the Pi from a TVs powered USB port, and turn on and shut down with the TV, but that is a poor solution:
- depowering the Pi this way will corrupt the SD card data;
- the boot time is too long and would diminish the user experience;
- The USB jacks on some TVs do not provide stable and sufficient power to the Pi (I know mine do not).

[davilla]

Sounds like a disto problem and not an xbmc issue.

[allan87]

Thanks for commenting. I'll see about posting at OpenELEC.

[barberio]

I suspect I've just figured out the cause for this, and a whole lot of other XBMC CPU hammering issues...

I was just trying to work out *why* I was seeing high CPU with the screen saver running, and had the log file open... And kept noticing that the error "ERROR: Texture manager unable to load file: special://skin/backgrounds/Grey.jpg" kept coinciding with CPU use spikes.

There is no Grey.jpg background in confluence. And I suspect that this is coming from a hardcoded expectation of that background existing in all skins. (And yet it doesn't exist in Confluence!) And for some reason, it's hammering CPU when that file isn't found.

The work around is obvious, create or symlink Grey.jpg in the skin you're using. Of course, you have to do this for all skins.

I expect the underlying bug that hammers CPU when a texture fails to load is buried in the graphics rendering system...

---

On a quick review... Looking for Grey.jpg isn't hardcoded, it happens when you switch from one skin to another skin, because XBMC continues to try to apply the skincolors and skintheme set in the old skin. This will occur any time anyone has set tried a different skin out, changed the theme/colour, then reverted back to the Confluence. Because Confluence doesn't have alternative themes, you can't even switch theme/colour in the settings to reset it because it only lists "Default" for them.

[allan87]

Which log? XBMC.log? I don't see that error.

I wouldn't call 30% (my typical reading on idle) hammering, but an inactive system really ought to be close to zero, and it would be if XBMC wasn't busy doing something unnecessary.

[barberio]

30% is as low as you can expect XBMC to get. There are issues with the graphics subsystem that mean it's CPU intensive, even when not doing anything.

[allan87]

It seems to me if it really, really isn't doing anything (which would be desirable when the TV is off) the CPU load would be down close to 0%. In fact, I have had occasions when the Pi has frozen up and the interface has remained visible on the TV screen, but the CPU is down to single digits.

It may only be about 5 watts, but that still 45 kilowatt hours a year.

[wsnipex]

thats true in an ideal world. Xbmcs GUI code is largely going back to the Xbox days, which required it being like a game. Changing that to a more modern approach is a huge and tedious task, specially considering it must be cross-platform.

[barberio]

XBMC could be transferred over to an off-the-shelf GUI toolkit... But that would require the following,

1) Break up XBMC from it's current monolithic state to at the very least a clear distinction between GUI and Function.
2) Replace or wrap all GUI functions with that of the GUI toolkit.

This is a long job, and could only rationally be under taken if there was a feature freeze, and a code branch to under take it.

XBMC's current developers are against under taking any feature freeze. So XBMC is going to be stuck with it's GUI.

Practically speaking, realistically the only way XBMC is going to function properly on embedded platform is if someone forks it to take it away from the demands of "more features in every new release". I don't have time to do this myself, it's going to be an epic project management task, and would probably really need someone who wasn't doing any code at all just managing the project.

[Ned Scott]

Realistic proposals will be considered. "don't add anything until it's fixed" is not a realistic proposal.

[wsnipex]

let alone that there aren't many GUI toolkits that support all our platforms..

[allan87]

Realistic proposals will be considered...

Not sure how realistic this, but I envision XBMC having a sleep mode in which all useless activity (like redrawing the screen while the TV is not in use) is shut down. Sleep could be triggered by inactivity, like a screen saver, and reactivated (also like a screen saver), by activity from an input device.

If a real sleep mode is not practicable, a not-bad solution would be a quasi-sleep: XBMC shutting itself down in an orderly manner and restarting as needed.

Shutting down video would have the further benefit of also putting many monitors to sleep.

When the Pi is idle, XBMC is the only process putting any material load on the CPU.

[wsnipex]

this is only an issue on some embedded platforms like the pi that don't support suspend...

[popcornmix]

this is only an issue on some embedded platforms like the pi that don't support suspend...

I don't think this is the real issue. The Pi when running 100% busy probably uses less power than your PC when suspended.

The issue is that when xbmc is not actively in use, you might want to do other things, like copy files, download a torrent, etc, which work faster when xbmc isn't using the majority of the cpu.