[Pyromaniac]

Hi XBMC-Team (and Fans )

I've tried OpenELEC on my Raspberry Pi (arrived today) and had to notice that the overall XBMC-Experience is very laggy.

When you look at this Video: http://www.youtube.com/watch?v=e_mDuJuvZjI you can see someone playing Quake3 on the Raspberry PI. But the same Hardware isn't fast enough for XBMC? I mean, whats so special about XBMC?
Is anyone interested in optimizing the code or do all the devs only want to put more and more features into XBMC?
If I would be able to code, I think this would be one of the first things I would look at.

Greetings
Pyro

[da-anda]

With the Android and the rPI ports we're ofc interested to improve performance of XBMC on such low power devices, if not we wouldn't have ported them. But we're no magicians. XBMC was never designed to run on those devices and our devs already made a whole lot of optimizations to get it even running on that 700 MHz processor. But up to some point we can't optimize the current codebase more and for some tasks (like database processing, calculations, filtering, ...) the 700 MHz are just not enough when also having to render the GUI and do whatever else in the background. AFAIK it would require a complete/large rewrite of XBMC to optimize it more for such devices and such a rewrite might be done some day in the future, but just not yet.

[opdenkamp]

if i would be able to build a space ship, i think the first thing i would look at would be saturn. but i'm too busy putting more and more features into xbmc so i don't have time to learn to do it

[Ned Scott]

Tons of optimization has already been done for ARM and other low-powered. Years (yes, years) worth of work have been put into ARM work by multiple developers for XBMC. In a lot of ways, XBMC hasn't been more leaner (outside of a few quirks here and there).

That being said, I wouldn't call XBMC on the Pi "very laggy". Sometimes, when the Pi is doing multiple things, updating add-ons in the background, loading large directory or library listings, or some fancy skin feature, it will screech to a halt, but normal operation is pretty good. I would say it runs better than it did on the old xbox. To really answer your question you'll need to be more specific with what you were doing that was so "laggy".

Compared to Quake, there's a few things that come to mind that might be issues:
• Quake, being a game, probably gets far more help from the GPU than XBMC can get for "normal operations". XBMC needs CPU power for accessing databases and all sorts of things.
• XBMC does a lot of reading from the SD card, where I'm assuming Quake can mostly run from RAM. The SD card kills us on lots of speed things, because even the fastest cards are still slower than most hard drives or even most USB thumb drives. The best thing someone can do to speed up XBMC on the Pi is to just use the SD card as a boot loader, but have the actual OS and XBMC installed on a fast USB drive. Even having the OS and XBMC installed on a network drive, or having the library hosted by a MySQL server, has sometimes shown better results than running on the SD card.
• It's possible XBMC is hung up on something in your set up, some bug or error, like it's trying to download something and won't give up, and that is causing a constant slowdown.

[Pyromaniac]

OK, thank you for your answers. Its good to hear that there are also optimizations going into the code

@ned Scott:
I've installed OpenELEC on a new SD-Card, startet it and watched whats going on. So, there are no Movies in any Database, no Live-TV activated, no plug-ins (beside the ones the are pre-installed) or something else. Also there is no SD-Card activity which will be shown with a blinking LED. The only thing that is running is the Ticker at the bottom of the screen. But you can see that XBMC is eating about 90% of the CPU cycles. I don't think that rendering a simple skin can really consume that much CPU-cycles, but what else is really going on in the background, and what is necessary?
The next thing: Starting a Movie (1080p) results in lesser CPU-consumption...I mean, THIS is the part where the CPU have to manage to stream the Data from the network, decode the Audio, and feed the GPU-Part with the "Picture"-Data, and -as already said- consumes less cpu-cycles. This is strange in my eyes. Its like my car starts munch diesel if I turn it OFF, and consumes less when I start driving

You also say that Quake runs from RAM, but XBMC from Disk/SD-Card. If you compare what Quake have to render, all the textures, polygon-models, the level itself, and also have to "render" the sound...honestly, with the right optimization, XBMC could run on an 386SX

But don't misunderstand my position, I love XBMC, I am glad there are developers who are coding every day in their free time to improve XBMC. As I said, I wish I could code too so I could help you, but I guess the only way I could help is to spend some money to you. Please don't see my postings as a provocation, it's more like a wish I hat to share with the guys who can do something about it (don't have to, just can )

@odenkamp: please go on building the space ship, I would like to see saturn too

[natethomas]

One should never get too caught up on CPU usage with embedded systems. It's almost entirely meaningless, which is why you very rarely see CPU measurements on Android or iOS. So long as the task at hand is working, everything else means very little.

As far as playback vs menus vs games goes, xbmc is extremely CPU intensive. Numerous scripts are running in the background, images are being decoded and buffered, engines are being maintained.

Meanwhile virtually none of that is occurring during playback or while gaming. In both cases, virtually every function is being offloaded to the GPU or hardware decoder, leaving the CPU with relatively little to do. Software decoding of audio can sometimes be a pain (particularly DTS) but it's nothing compared to the intensive efforts necessary to created an interactive menu for XBMC.

To summarize my and everyone else's point, XBMC is HIGHLY CPU efficient compared to only a few years ago, but there's only so much that can be done without a complete rewrite of potentially millions of lines of code. Half the team has dedicated almost all of their coding contributions to making XBMC run more efficiently (see the Pivos devs), but there's only so much magic anyone can do.

[Ned Scott]

The Pi is great because it's standard and cheap, not because it's powerful. I have no doubt that if you throw enough time, money, and man power at it, you could have the XBMC running on a toaster.

The RSS feed is actually one of those quirks that probably could be optimized better. Considering most people just turn it off when they install XBMC (I'm honestly not sure why OpenELEC doesn't have it disabled by default), it's not exactly high on the priority list.

Video playback uses less CPU because hardware video decoding takes care of most of data crunching, not the CPU. It's not trying to dynamically render a GUI or do database updates. Speaking of the GUI, you can't have it both ways, you can't have a flexible, skinnable, extremely tweakable GUI, and expect it to be perfectly optimized for the specific view that is currently loaded.

There's also different bottlenecks that different applications will run into. XBMC is heavy on database/SQL usage, while Quake isn't. Programs aren't just all the same "thing". The entire GPU market basically exists to make games less taxing for the CPU, and you wonder why a 14 year old Quake runs better?

In the Raspberry Pi, the CPU is literally the GPU's bitch. The CPU on the Pi wasn't originally meant to be used as a normal CPU, but as a way to assist the GPU (for a lack of better words). The CPU/GPU (the ARM chip) was chosen because it could still do a fairly good job and was extremely cost efficient. (it's an educational tool, remember)

You must understand that what you're saying here is insulting. Not because you're saying the Pi is a poor performer; lots of people will agree with you there. It's because you insinuate that no one even thought to optimize the code, like it just slipped our minds. As if years worth of work hasn't been spent on ARM optimizations and porting.

Considering much more powerful ARM processors are reaching the same price point as the Raspberry Pi, you have to ask yourself, what good would it be to optimize XBMC any further. The more you optimize something, the less flexible it becomes. The fact that XBMC runs on multiple types of processors, as well as multiple operating systems, is one of the biggest strengths of XBMC, and no one is going to sacrifice that just to make a $35 box run XBMC better.

[Pyromaniac]

Ok guys, I think now I understand a bit more why things are like they are in XBMC. Thank you for taking the time to answer my question in detail

[Chris!]

I have no doubt that if you throw enough time, money, and man power at it, you could have the XBMC running on a toaster.

Sweet!

[Ned Scott]

I have no doubt that if you throw enough time, money, and man power at it, you could have the XBMC running on a toaster.

Sweet!

[doveman2]

To get the CPU at idle down from 90% to 45%, you need to disable the "Show recently added" skin settings, assuming the skin you're using has those (Confluence does). Disable RSS scrolling and weather animations as well as there's a problem with animations/scrolling text, which hopefully can be fixed one day. http://forum.xbmc.org/showthread.php?tid=160853

Even overclocked to 900/350/425 I do still find XBMC on the Pi rather laggy. For example, scrolling through the movies on Poster View it can get a bit behind and I have to wait for it to load the posters but once it's done that and cached them it's much smoother. Changing screens from Home seems a bit slow as well and I notice the delay as Home fades out and the new screen appears but it's bearable. Navigating the Timeline EPG is quite laggy but that's probably because the CPU is fully loaded due to the scrolling issue.

I'm using a USB3 stick for OpenElec's storage partition and the SD card is just used to boot and then OE loads into ram anyway so it isn't used anymore. Testing with dd I get 10.3MB/s with the USB stick and 12MB/s with the SD (writing) and 28.3MB/s with the USB stick and 23.3MB/s with the SD (read), so there's not a lot of difference and I'm mainly using the USB stick to help prevent the SD getting corrupted, which it's prone to when overclocking. In a USB2 port on my PC, the USB3 stick gives 34.83/11.69 Read/Write, so it's a bit slower in the Pi.

I ran NFSBoot for a while but that was noticeably slower than USB.

[aptalca]

I have no doubt that if you throw enough time, money, and man power at it, you could have the XBMC running on a toaster.

Sweet!

lol great kitchen appliance to watch cooking shows on