[Martijn]

to add from a dev point of view. the guys from OpenELEC actively contribute improvements back from what they find. RaspBMC on the other hand has so far done squat, zero, nothing.

Sure he/they packages all improvements but so far as actual code contributions I have not seen anything that has made it to our master code branch.

Just to be clear:
I do not mean this as any offence what so ever to a group or a person. This is a pure observation. With this in mind alone OpenELEC is the pure winner for better support and improvements. This is my personal statement and not connected to the team what so ever.

[ActionA]

So Miappa's builds and his user base have been of zero productive value? That thread is quite large so I find that hard to imagine Martijn...

[Martijn]

So Miappa's builds and his user base have been of zero productive value? That thread is quite large so I find that hard to imagine Martijn...

Miappa is doing a great job by creating test builds. Him providing these builds gives a better/larger userbase and tester that help improve to find issues. However from raspbmc devs there no code contributions. I was not talking about anything else than code.

Besides this this is off topic for this thread.
My conclusion from actuall testing both is that OE is still better than Raspbmc

[hghfdkjbfjb]

to add from a dev point of view. the guys from OpenELEC actively contribute improvements back from what they find. RaspBMC on the other hand has so far done squat, zero, nothing.

Sure he/they packages all improvements but so far as actual code contributions I have not seen anything that has made it to our master code branch.

Just to be clear:
I do not mean this as any offence what so ever to a group or a person. This is a pure observation. With this in mind alone OpenELEC is the pure winner for better support and improvements. This is my personal statement and not connected to the team what so ever.

That makes sense though since it's a huge multiplatform project that uses XBMC. The thing is that the Raspberry Pi is a slightly more specialized platform and needs extra attention to achieve good performance. Raspbmc leverages the existing work done with Raspbian which has a huge community, whereas OpenELEC is a smaller team (compared with Raspian) compiling the whole stack for the Pi. It's believable that less Pi-specific tweaks find their way into the entire stack.

Anyway, I don't like arguing, it's not my intention. I just like to stress that I have personally had a much better experience with Raspbmc and while some others might have experienced the opposite, I'm surprised it doesn't get at least a mention :-(

[wrxtasy]

I will say only one thing, Openelec is easy as to configure for the newbie especially. Plug and Play and no terminal configs!

Back on topic......

@ Ned Scott - > I think some importance should be given to Library browsing speeds and the correct storage of networked external media files in their own folders with accompanying Metadata.
It certainly seemed to make a Speed difference on my RPi once I organised my library correctly and started to scrape externally via a decent media manager.

Maybe a short sentence and and an appropropriate link should go under the heading Maximizing Performance ?

[popcornmix]

@ Ned Scott - > I think some importance should be given to Library browsing speeds and the correct storage of networked external media files in their own folders with accompanying Metadata.
It certainly seemed to make a Speed difference on my RPi once I organised my library correctly and started to scrape externally via a decent media manager.

Agreed. Separate directories for each movie is a big speed win compared to a single folder with a hundreds of movies and all the associated artwork/subs.
The people who complain it takes 30 seconds to start a video are generally in the single folder for everything camp.

[ActionA]

Besides this this is off topic for this thread.
My conclusion from actuall testing both is that OE is still better than Raspbmc

Well, the fact that Raspbmc is maintained by a single dev (and still has achieved so much) would surely affect how much that dev could contribute to XBMC/Kodi. But for the entire user base of Raspbmc, >90k unique daily connections to the update server, to be effectively written off in the eyes of XBMC/Kodi based on subjective preference seems remiss...

---

I will say only one thing, Openelec is easy as to configure for the newbie especially. Plug and Play and no terminal configs!

What is so difficult to configure? What requires terminal?

[wrxtasy]

What is so difficult to configure? What requires terminal?

WIFi issues on the RT5370 for one...

This is not the thread for discussing Raspbmc vs Openelec its supposed to be about Maximising Speed.

Another Suggestion:

-> Set GUI resolution limit ....720

This definitely seemed to help on higher textured skins...

[ActionA]

Indeed, the thread is about an XBMC/Kodi wiki post for maximising speed on the Raspberry Pi. And the only choice, if one was to put any stock in the currently written wiki page, is the use of OE.

Where is the objectivity here? We all use XBMC/Kodi, we love it, but where are the facts supporting these claims? XBMC/Kodi is an open source binary package that runs on an OS. In terms of the performance of this package, how can XBMC endorse one distro over any other when there are obviously thousands of users who, in their use cases, find another alternative that performs better for them? It does users a disservice to be told that they only have one option here, which may not necessarily net them the greatest experience possible.

Yeah, RT5370 seems to generally only be an issue under NOOBS. If a user requires a dual-boot system and uses RT5370, maybe OE is right for them if they happen to use this chipset and refuse anything less than a plug-n-play system. I'd hardly call this a large or majority share.

[Sam.Nazarko]

Hi,

I know this is about getting performance, but I'd like to weigh in a bit. I think that OE and Raspbmc/OSMC can co-exist. I am happy to post in this thread because it seems balanced, rather than covered with unfounded arguments of one distro over another. I think OE is too closed down myself, but some will love that. Either way -- having more than one distribution only helps drive the competition and gives the user a better end result.

to add from a dev point of view. the guys from OpenELEC actively contribute improvements back from what they find. RaspBMC on the other hand has so far done squat, zero, nothing.

Sure he/they packages all improvements but so far as actual code contributions I have not seen anything that has made it to our master code branch.

Just to be clear:
I do not mean this as any offence what so ever to a group or a person. This is a pure observation. With this in mind alone OpenELEC is the pure winner for better support and improvements. This is my personal statement and not connected to the team what so ever.

OpenELEC contributes actively upstream, which is good for Kodi. I wish I was able to do this: I tried helping with AirPlay issues around this time last year; but without an iOS device it was tricky. A lot of the changes I make only make sense downstream (they are not portable and rely on the underlying distribution's implementation). Part of what has hindered my ability to contribute upstream has been the fact that I am a sole developer of both Raspbmc and Crystalbuntu. Consider my typical daily workflow:

• cherry pick upstream XBMC commits
  
• check downstream patches (for example, popcornmix/gotham_rbp_backports)
  
• test and verify that builds resolve issues and are stabl
  
• implement *other* raspbmc/crystalbuntu features users have requested
  

At the moment, the workflow for Raspbmc/CB is not great, and I'm hoping with the new project, OSMC, which has a unified codebase, I will be able to spend more time looking at upstream. OE does help devs get quick snapshot builds for a few platforms, which does accelerate development. But we do this too.

So Miappa's builds and his user base have been of zero productive value? That thread is quite large so I find that hard to imagine Martijn...

Miappa is doing a great job by creating test builds. Him providing these builds gives a better/larger userbase and tester that help improve to find issues. However from raspbmc devs there no code contributions. I was not talking about anything else than code.

Besides this this is off topic for this thread.
My conclusion from actuall testing both is that OE is still better than Raspbmc

Our attempt to offset a lack of upstream dev was to provide 24 hour test builds (installable via the GUI). This way devs didn't have to at least worry about building nightlies and could just get their changes straight on to a Raspbmc user's Pi. I would like to think Raspbmc has helped XBMC / Kodi on the whole grow. Raspbmc is synonymous with the idea of Raspberry Pi and XBMC, for better or worse. And ease of installation probably helped that in the early days before NOOBS. I hope OSMC lets us contribute upstream. It is important to keep Kodi alive -- a rebranding must be costly, and so OSMC will donate resources to the Kodi project. Without Kodi the OSMC project would not exist, so it's important to make sure Kodi can thrive. I'll be emailing Nate about that in a couple of days.

miappa does a great job as does popcornmix (bavison too!) in improving the Pi's XBMC performance. But this is very platform specific: to Windows users these contributions aren't necessarily recognised, but it's the same for those working on DXVA2 improvements.

That makes sense though since it's a huge multiplatform project that uses XBMC. The thing is that the Raspberry Pi is a slightly more specialized platform and needs extra attention to achieve good performance. Raspbmc leverages the existing work done with Raspbian which has a huge community, whereas OpenELEC is a smaller team (compared with Raspian) compiling the whole stack for the Pi. It's believable that less Pi-specific tweaks find their way into the entire stack.

That's not quite right. Raspbian is a very basic root filesystem (we debootstrap it), but all other packages related to XBMC are built manually. Everything is completely optimised: scheduler; read_ahead; sysctl etc independent of any Raspbian configuration. We are greatful for upstream contributions, such as libcofi; but that is in OE too. If anything OE have a slight advantage in that they build their own toolchain and can stay on top of GCC releases, where we have to stick with the distribution's version for binary compatibility.

Yeah, RT5370 seems to generally only be an issue under NOOBS. If a user requires a dual-boot system and uses RT5370, maybe OE is right for them if they happen to use this chipset and refuse anything less than a plug-n-play system. I'd hardly call this a large or majority share.

The issue regarding RT5370 will be resolved once we refresh our NOOBS image. This will likely be within the next week.

I'd like to think the reason there is less material on optimising Raspbmc, is because there is much less to do. Looking at some references to OE, I see the scheduler is changed to deadline. IMHO this should be 'noop'. Regardless -- Raspbmc uses an optimised scheduler already: I am a little surprised OE is using CFQ.

In terms of performance, clock for clock, I think OE has a slight edge. This is likely due to a more modern compiler used, where as we are still using an old GCC pre-4.7 toolchain. On OSMC, we've started using 4.9, and the performance difference is noticeable, and brings performance back to where it should be.

I do hope when OSMC lands on Pi in the next month or so I'll be able to just say 'install it and enjoy it', rather than having users needing to squeeze performance.

Thanks, and I do hope above all, regardless of the distro you use, you get what you want from your device.

Sam

[BenH]

I think another thing that can affect performance is the format of the external drive (if using one). Apparently NTFS formatted drives will perform worse on a Pi than Ext3/4. Don't know if this applies to the filesystem format of a NAS or not?

(for the record, I'm using Raspbmc as I found it played the high bitrate content I have, over my network, better at the time I tested Raspbmc, Openelec and Xbian. I haven't tested for a while now)

Ben

[Ned Scott]

I have no scientific tests or data to backup any claim I have made. I have read a great many posts on the forums, and those posts confirm what I have personally experienced. That being said, I don't think there's a major difference in performance between OE and Raspbmc. I have no issue removing the "use OE" line from the list of things to maximize performance, because most of the things on that list are far more significant and are universal to any installation.

Like I said, I am skeptical, but not close minded. I'm willing to be swayed, and I have been.

Off topic, as far as contributions upstream to XBMC/Kodi go, that is simply not a factor here. I would never hold the number of pull requests against anyone. I think that is against the spirit of the GPL. The GPL says you just make your changes available to others, it does not say that you must also work to have those changes adopted. It is the responsibility of both sides, as well as third parties, to see to the improvement of the project. If someone hasn't make a pull request then someone else can do it on their behalf. That's assuming those code changes are even appropriate for upstream. Sometimes a pull request is not done simply because it wouldn't make sense on the larger scale, even if it helped a forked version.

In any case, there are too many factors involved to judge upstream contributions at face value. There are also countless other ways to contribute to a project than in code. Sam's Crystalbuntu remains a favorite project of mine and had a big hand in me being involved in the greater XBMC community, for example.


Remember, both distros have their place. I find myself using both to the point that they're often installed on the same SD card in a dual-boot configuration.

[ActionA]

Thanks for such a thoughtful, reasonable, and open minded response Ned. These are the things that make XBMC/Kodi, best in it's class! Proud to be a user of such a great piece of software, no matter what distro it runs on

[Ned Scott]

@ned Scott

There is some stuff in this thread, it is pretty specific to OpenELEC but there is some other stuff in there too like the IO scheduler.

http://forum.xbmc.org/showthread.php?tid=201354

Nice! I haven't dove much into this yet, but I've already included a link to the thread for the time being.

Pre-loading the texture cache can help the UX, although in most cases this shouldn't be necessary if the scanner has done it's job properly and the Pi isn't being used in a MySQL environment. When the Pi is being used in a MySQL environment it's unlikely to be the "scanner"* so it will be missing all the new artwork when the user goes to use the Pi, in which case pre-loading the cache can make a big difference to performance.

* I guess most people might use their most powerful kit to scan the library although once the library has been scanned the first time, the Pi is perfectly capable of being used to scan only new media pretty quickly (particularly if it's only reading local metadata).

There's likely enough MySQL users to warrant a mention. Thanks for the reminder.

@ Ned Scott - > I think some importance should be given to Library browsing speeds and the correct storage of networked external media files in their own folders with accompanying Metadata.
It certainly seemed to make a Speed difference on my RPi once I organised my library correctly and started to scrape externally via a decent media manager.

Maybe a short sentence and and an appropropriate link should go under the heading Maximizing Performance ?

I've always been more fond of just letting XBMC/Kodi scan media in, but since this is the Pi, this makes perfect sense. I've heard this can also improve browsing speeds even after scanning, since XBMC/Kodi looks for supporting files like subtitles on a constant basis.

I think another thing that can affect performance is the format of the external drive (if using one). Apparently NTFS formatted drives will perform worse on a Pi than Ext3/4. Don't know if this applies to the filesystem format of a NAS or not?

(for the record, I'm using Raspbmc as I found it played the high bitrate content I have, over my network, better at the time I tested Raspbmc, Openelec and Xbian. I haven't tested for a while now)

Ben

An excellent point. This mainly just affects media directly connected to the Pi, but I've noted it as being true for most linux-based systems, which include many NAS devices. People can likely see a speed increase even when using a NAS because the linux-based NAS will be accessing the data faster.

[wrxtasy]

Good move Ned removing the bias toward Openelec from the Wiki.
I've been a fan of Sam Nazarko's Crystalbuntu distributions for a while now and only switched to RPi after 1080p Crystalbuntu issues became unbearable with XBMC Gotham.

I've always been more fond of just letting XBMC/Kodi scan media in, but since this is the Pi, this makes perfect sense. I've heard this can also improve browsing speeds even after scanning, since XBMC/Kodi looks for supporting files like subtitles on a constant basis.

The other thing I found after running Milhouse's Texture Cache Maintenance utility is that with proper media metadata folder structure (after local file scanning) all my media textures were already being pre-cached by XBMC in the Textures13.db.
Very few were missing - likely due to a comprehensive external metadata scraper.

The other point that should not be lightly discounted is that once metadata is stored in the proper structure externally you then have very Speedy portable library that can be used on other XBMC distributions. This becomes very important when an External hard drive name changes or a library is consolidated from multiple drives.

As an example when I scraped over 1600 movies using local .nfo into my XBMC iMac with this folder setup, scraping was finished in less than 1 minute. Now thats a Speedy portable library !

Most users start with a small XBMC library that increases in size over time which then starts slowing down XBMC. RPI XBMC users in particular should be actively encouraged for their own sake to employ proper metadata folder structure from the initial setup.

In fact I would put the importance of correct metadata folder structure at the top of the list with a bullet for RPi library browsing speed with a large library.
That and overlocking have made the most difference IMHO.