OpenELEC Testbuilds for RaspberryPi

My new custom build.

http://www.mediafire.com/?10456ccz13ard

- OpenElec build r13108
- Xbmc Frodo Final !!! (27.01.2013) with new video codecs:MJPEG, VP6, VP8, Ogg Theora and audio codec: Ogg Vorbis for Rpi.
- Rpi kernel 3.6.y (22.01.2013)
- Rpi firmware (26.01.2013)
- Pvr Addon (18.01.2013)
- Xvdr Addon (11.01.2013)
- Gpu memory set to 100mb on default for Rpi 256mb (fix kernal killing Xbmc task on Rpi 256mb board) and Gpu memory set to 256mb on default for Rpi 512mb.
- Memory cache set to 2621440 on default
- GUI resolution switch (taken from XBIAN)

Add to advencedsettings <guires>XXXX</guires>

XXXX = GUI resolution. 480p,720p,900p,1080p. <guires>720</guires>, <guires>1080</guires> etc...

Update Instruction:

http://openelec.tv/installation/updating

For Rpi 512Mb set gpu_mem=256, cachemembuffersize to 5242880 and change GUI to 1080p.

For Rpi 256Mb set gpu_mem=100, cachemembuffersize to 2621440 and change GUI to 900p.

If you want try new codecs add this line to config.txt

start_file=start_x.elf
fixup_file=fixup_x.elf

or clean install:

http://wiki.openelec.tv/index.php?title=...spberry_Pi

(2013-01-28 10:26)MilhouseVH Wrote:  

(2013-01-28 10:01)pplucky Wrote:  

(2013-01-28 09:56)Wanderlei Wrote:  I have a 512MB board that does this. If I overclock core_freq by even 1 to 251, I can reproduce ext4 corruption first reboot every time. I have tried different SD cards and it still corrupts.

Just like me. I fixed it by changing the whole STORAGE partition to an USB pen instead and I didn't have a single problem after that.

Yes, but even when using USB it's quite likely you'll be left with an unbootable system if you experience these mmc0 errors when your Pi boots in order to apply a software update (updates to the SD-based kernel.img, bootcode.bin etc.). The only solution (other than avoiding/eliminating the mmc0 errors) is to move /storage to USB/NFS, and apply SD-card based updates manually using a PC (ie. disable auto-update, and never allow the Pi to write to the SD card, basically).

Yes, that is exactly what happens to me... Corruption after each update!

Does this mean that if I either disable the overclock before updating (my past experience shows that this ALWAYS cause corruption in SD card) or manually move SYSTEM and KERNEL files to the SD SYSTEM partition (via PC), it should work?

Any downside of moving these files manually (other than MD5 not being checked)?

(2013-01-28 13:11)pplucky Wrote:  or manually move SYSTEM and KERNEL files to the SD SYSTEM partition (via PC), it should work?

Any downside of moving these files manually (other than MD5 not being checked)?

I often do this and it works fine. You should rename KERNEL to kernel.img (or add kernel=KERNEL to config.txt).

(2013-01-28 13:54)popcornmix Wrote:  

(2013-01-28 13:11)pplucky Wrote:  or manually move SYSTEM and KERNEL files to the SD SYSTEM partition (via PC), it should work?

Any downside of moving these files manually (other than MD5 not being checked)?

I often do this and it works fine. You should rename KERNEL to kernel.img (or add kernel=KERNEL to config.txt).

Perfect, thanks a lot.

Always learning from the community.

(2013-01-28 13:11)pplucky Wrote:  disable the overclock before updating (my past experience shows that this ALWAYS cause corruption in SD card)

Probably...

(2013-01-28 13:11)pplucky Wrote:  or manually move SYSTEM and KERNEL files to the SD SYSTEM partition (via PC), it should work?

Yes.

(2013-01-28 13:11)pplucky Wrote:  Any downside of moving these files manually (other than MD5 not being checked)?

You'll also need to also extract the third-party binaries (bootcode.bin, start_elf, fixup.dat), in addition to KERNEL/kernel.img and SYSTEM.

(2013-01-28 14:01)MilhouseVH Wrote:  

(2013-01-28 13:11)pplucky Wrote:  Any downside of moving these files manually (other than MD5 not being checked)?

You'll also need to also extract the third-party binaries (bootcode.bin, start_elf, fixup.dat), in addition to KERNEL/kernel.img and SYSTEM.

If it is updating, it means the partition already contains it. In that case, do I also need to do that? Where should I extract it from then?

(2013-01-28 14:04)pplucky Wrote:  If it is updating, it means the partition already contains it. In that case, do I also need to do that? Where should I extract it from then?

Yes, as they sometimes change from one release to the next (for instance in the last few days, updated thirdparty binaries were included in all OpenELEC releases).

If you let OpenELEC update itself, these third party binaries will be extracted from within the new SYSTEM file.

If you are updating manually, you need to copy them yourself to the SD card. If you are downloading the tar.bz2 file, they should be in a folder called 3rdparty/bootloader (not sure about the zip packages, but probably similar).

(2013-01-28 13:06)rbej Wrote:  My new custom build.

http://www.mediafire.com/?10456ccz13ard

...

That's a really good job, working perfectly on my 512Mb Pi!
Thanks for that!
Would you be able to produce a build including an mpd server? I had a look on tutos for creating an add-on or modifying openelec sources, but I don't understand anything..

(2013-01-28 12:32)MilhouseVH Wrote:  Not sure if those items are related, as with my own builds h264 returns to 0MHz after playback ends, though bogomips is calculated as 666 despite running a 1GHz overclock.

Weird the official RC2 from openelec.tv does not. Return to 0 that is. At any point. Builds up to RC2 did.
Oh well..

(2013-01-28 13:11)pplucky Wrote:  

(2013-01-28 10:26)MilhouseVH Wrote:  

(2013-01-28 10:01)pplucky Wrote:  Just like me. I fixed it by changing the whole STORAGE partition to an USB pen instead and I didn't have a single problem after that.

Yes, but even when using USB it's quite likely you'll be left with an unbootable system if you experience these mmc0 errors when your Pi boots in order to apply a software update (updates to the SD-based kernel.img, bootcode.bin etc.). The only solution (other than avoiding/eliminating the mmc0 errors) is to move /storage to USB/NFS, and apply SD-card based updates manually using a PC (ie. disable auto-update, and never allow the Pi to write to the SD card, basically).

Yes, that is exactly what happens to me... Corruption after each update!

Does this mean that if I either disable the overclock before updating (my past experience shows that this ALWAYS cause corruption in SD card) or manually move SYSTEM and KERNEL files to the SD SYSTEM partition (via PC), it should work?

Any downside of moving these files manually (other than MD5 not being checked)?

When using the USB, the only time the SD should be written to (with the risk of corruption) is when updating, so disabling the overclock before updating should be all that's required. I don't see any advantage in moving the files manually, as that still involves writing to the SD and therefore needs the overclock disabling first.

What I'd like to see ideally to make this less complex is an automated method where it disables the overclock, reboots (now not overclocked) and installs the updates, reboots again and re-enables the overclock and reboots a last time (now with the overclock re-enabled), to save the user having to do all this manually.