• 1
  • 71
  • 72
  • 73(current)
  • 74
  • 75
  • 174
OpenELEC Testbuilds for RaspberryPi
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.
Forget it..
(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?



(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.
(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.
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.
(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.
(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.
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.
(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.
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.
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.
  • 1
  • 71
  • 72
  • 73(current)
  • 74
  • 75
  • 174

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi12