OpenELEC Testbuilds for RaspberryPi

  Thread Rating:
  • 12 Votes - 4.58 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Closed
doveman2 Offline
Posting Freak
Posts: 815
Joined: Nov 2012
Reputation: 2
Post: #1081
I'm using 512MB RPi's so I probably don't need SWAP anyway but I'd be wary about using it on SD or USB anyway, simply because constantly writing to flash media generally isn't recommended and I'd try to avoid anything that might result in the SD or USB failing, as it's not very user-friendly if users have to open up their media centers and replace either device (I hide the USB stick inside the case as well as the SD), not to mention installing the image to the new SD/USB and copying across their backed-up settings from the old install.

Of course, if XBMC is going to keep crashing, etc on a 256MB RPi without SWAP enabled, then that's not very user-friendly either so I can appreciate it might be the lesser of two evils.
find
tuxen Offline
Fan
Posts: 365
Joined: May 2011
Reputation: 6
Post: #1082
Forget it..
(This post was last modified: 2013-01-28 09:05 by tuxen.)
find
Wanderlei Offline
Member
Posts: 95
Joined: Aug 2012
Reputation: 0
Post: #1083
(2013-01-27 20:34)MilhouseVH Wrote:  Anyone suffering from corruption of the ext4 (secondary) partition when booting OpenELEC based Pis is probably falling victim to the following problem.

My solution right now is to try and detect when the SD card is misbehaving and reboot the Pi until it behaves itself (which is usually the next reboot, very occasionally it may take two reboots). Would this suggest its some sort of timing/race issue?

Good stuff.

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.

-----

Is there any way to improve SMB performance?

I can stream media no problem the majority of the time. Then other times I will get hit with buffering. I dont understand what causes it, literally nothing in the entire setup changes. I simply cant isolate what the problem is?
find
pplucky Offline
Senior Member
Posts: 111
Joined: Nov 2012
Reputation: 1
Post: #1084
(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.
find
tfft Offline
Junior Member
Posts: 47
Joined: Nov 2012
Reputation: 1
Post: #1085
(2013-01-28 00:32)popcornmix Wrote:  cachemembuffersize comes from arm memory. It is multiplied by 3 (there is a file buffer, a "skip back" buffer and a "skip forward" buffer to allow small seeks).
It gradually grows as time elapses until it reached the limit.

Personally I would recommend enabling swap (with a low swappiness value) on a 256M board.
So I take it the assumptions/explanation noted was in the right track (ie. correct) - do please let me know otherwise.

As for SWAP - why the "low swappiness value" ? Given ample disk space (assuming it is robust enough to work and work properly), what is the harm in having a large swap ? In other words, if I'm using an 8GB card, what's the harm in using say 5GB for swap ? The swap should only be used when needed anyways and so, in principle, it should not be over utilized or used heavily.

Thanks.
find
tfft Offline
Junior Member
Posts: 47
Joined: Nov 2012
Reputation: 1
Post: #1086
Top (and the improved version of it - htop) exist to get details on the CPU and its memory. Does something similar exist to detail the GPU's utilization along with the usage of its dedicated memory ?

Thanks.
find
Milhouse Offline
Team-Kodi Member
Posts: 3,747
Joined: Jan 2011
Reputation: 88
Post: #1087
(2013-01-28 10:23)tfft Wrote:  Top (and the improved version of it - htop) exist to get details on the CPU and its memory. Does something similar exist to detail the GPU's utilization along with the usage of its dedicated memory ?

You could try:

Code:
wget http://www.nmacleod.com/public/bcmstat.sh && chmod +x ./bcmstat.sh
./bcmstat.sh -x

It doesn't give you GPU utilisation as such (ie. 25% or what is using it), but you can see when it and the h264 block is being used (the latter should be off when not in use).
(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).

The annoying thing about the errors I am (and I'm sure many others are) experiencing is that the Pi is 100% stable in all other respects, it only experiences these partition and file corrupting mmc errors randomly once in 8 or 10 boots, which would suggest it's more a case of being a firmware issue than unstable hardware. Sadly once is enough to completely trash the installation.

That said, some Pi's are simply lemons when it comes to overclocking - I had one that also couldn't cope with a +1Mhz core overclock.

For those with stable Pis that experience occasional (but devastating) corruption when booting OpenELEC, I've put together an OpenELEC kernel that attempts to detect these boot-related mmc0 errors early in the boot sequence and force a reboot, if anyone wants to test it, it's here - just replace your normal kernel.img (take a backup first!)

To see more of what is going on you can add "nosplash debugging progress" to the end of your boot entry in cmdline.txt. If you want to access a debug shell (dmesg is included in this kernel, which can help determine the state of your SD card), append "break=all" and you will get a debug shell after each major step (in sequence: load_modules, check_disks, mount_flash, media_check, load_splash, mount_storage, check_update, prepare_sysroot). Type "exit" or hit ctrl-d to continue booting to the next break point (you can also break after a specific step, for example, "break=load_splash"). "media_check" is a new step in this kernel, which attempts to identify if the SD card is likely to encounter corruption and if so, it forces an unconditional reboot (it's a hack, but it seems to work for me and I can live with the occasional extra reboot rather than a system that requires rebuilding).

Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(This post was last modified: 2013-01-28 11:40 by Milhouse.)
find
tuxen Offline
Fan
Posts: 365
Joined: May 2011
Reputation: 6
Post: #1088
(2013-01-28 10:26)MilhouseVH Wrote:  You could try:

Code:
wget http://www.nmacleod.com/public/bcmstat.sh && chmod +x ./bcmstat.sh
./bcmstat.sh -x

It doesn't give you GPU utilisation as such (ie. 25% or what is using it), but you can see when it and the h264 block is being used (the latter should be off when not in use).
The latter H264 is NOT off anymore with the official RC2 when not in use but on constantly. Along with the bogomips bug. As I reported. 2 not so influential but very odd bugs. Try install it from openelec.tv and you will see. Even gives a small heat increase in the GUI.
(This post was last modified: 2013-01-28 12:29 by tuxen.)
find
Milhouse Offline
Team-Kodi Member
Posts: 3,747
Joined: Jan 2011
Reputation: 88
Post: #1089
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.

Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
find
popcornmix Offline
Team-Kodi Member
Posts: 2,740
Joined: Feb 2011
Reputation: 66
Post: #1090
(2013-01-28 10:26)MilhouseVH Wrote:  For those with stable Pis that experience occasional (but devastating) corruption when booting OpenELEC, I've put together an OpenELEC kernel that attempts to detect these boot-related mmc0 errors early in the boot sequence and force a reboot, if anyone wants to test it, it's here - just replace your normal kernel.img (take a backup first!)

I'd be interested to hear if this helps.
find
rbej Offline
Fan
Posts: 637
Joined: Sep 2012
Reputation: 25
Post: #1091
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




(This post was last modified: 2013-01-28 13:58 by rbej.)
find
pplucky Offline
Senior Member
Posts: 111
Joined: Nov 2012
Reputation: 1
Post: #1092
(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)?
find
popcornmix Offline
Team-Kodi Member
Posts: 2,740
Joined: Feb 2011
Reputation: 66
Post: #1093
(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).
find
pplucky Offline
Senior Member
Posts: 111
Joined: Nov 2012
Reputation: 1
Post: #1094
(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.
find
Milhouse Offline
Team-Kodi Member
Posts: 3,747
Joined: Jan 2011
Reputation: 88
Post: #1095
(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.

Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
find
Thread Closed