Kodi Community Forum

Full Version: OpenELEC Testbuilds for RaspberryPi Part 2
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Thats good - as long as I remember to toggle the write protect on update :-)
(2013-10-18, 11:54)Johnkg Wrote: [ -> ]I still boot from NFS as I assumed it stopped SD card corruption and ran quicker. Is that no longer the case?

Yes, booting via NFS can eliminate SD corruption, but so can disabling auto-update and using disk=NFS so that only /storage is mounted over NFS. However booting via NFS is never going to be the quickest option, unless you've got a really awful SD card.

With auto-update disabled and booting from /dev/mmcblk0p1, should you want to try a manual update you can just drop the files in the Update folder and cross your fingers. When "booting" via NFS you've got to manually perform the update - copying the SYSTEM file to your NFS partition, and the rest of the files to your SD card, which could still corrupt itself unless you perform the update in your PC.

Bottom line, there's no benefit to booting over NFS.

(2013-10-18, 12:41)hudo Wrote: [ -> ]** EDIT **
I keep my SD cards locked! No corruption.

Nice idea, but the Pi has no way of reading the locked/unlocked status of the SD card as the pin isn't connected on the SD socket... Wink

(2013-10-18, 14:19)RichG Wrote: [ -> ]Does the System file ever get written to?

In other words, if the System file is on SD card can it still be write protected?

As stated by trogggy, the primary SD partition will be written when updating OpenELEC. Normally this partition is mounted read-only, but will be mounted writable during the update, during which time corruption can - if you're unlucky - occur.

If you want to eliminate the risk of SD card corruption, disable auto-update, boot from /dev/mmcblk0p1 with NFS, SMB or USB used for disk, and then update firmware on the SD card primary partition using only your PC...
One of my Pis boots from a 128 MB SD card that is at least 10 years old. Storage is on USB. I don't see what benefit there is to a bigger or faster card if it is only read during boot up and only written to during an update, or if you edit the config or command files.

I also don't see how corruption of the system partition could even be an issue. How is it going to be corrupted if is never being written to in everyday use?
(2013-10-18, 16:22)allan87 Wrote: [ -> ]One of my Pis boots from a 128 MB SD card that is at least 10 years old. Storage is on USB. I don't see what benefit there is to a bigger or faster card if it is only read during boot up and only written to during an update, or if you edit the config or command files.

Same here.

(2013-10-18, 16:22)allan87 Wrote: [ -> ]I also don't see how corruption of the system partition could even be an issue. How is it going to be corrupted if is never being written to in everyday use?

Obviously, not all Pi's are prone to corruption, but for those that are...

If your only SD card partition is the primary boot partition, your only chance of corruption is while updating, or when modifying configuration files, as these are the only times the partition should be written to. Although it's unusual for the FAT partition itself to be corrupted, it's not unusual to see corrupt files written that render the device unbootable until the corrupt files are overwritten with working versions.

However if you have both primary and /storage partitions on the SD card, it's quite likely that the /storage partition will be corrupted as it is first mounted, hence moving the /storage partition to NFS, SMB or USB to significantly reduce the risk of complete system failure due to corruption. Even cleanly unmounted /storage partitions have been corrupted when next mounted.

I once wrote a method for detecting during OpenELEC boot when the SD card wasn't correctly initialised, it involved timing how long it would take to write a 1MB file to the FAT partition - it should normally take <1 second but there were times when it would take 10-15 seconds. I would have the Pi reboot itself when these abnormal IO times were detected and it eliminated corruption of both firmware (during any subsequent update) and of the secondary /storage partition whenever it was mounted. Not a nice solution by any means, but it worked pretty reliably. I've since given away that Pi which suffered from corruption, and my current Pi doesn't have any SD corruption problems...
is anyone experience rebooting issues without anything showing in the logs? Either a bug or my power supply went downhill between updates. im lucky if i can get a couple of hours between reboots. wonderered if it was my overclcock, so went back to 700 from 1150 and still the same, couple of hours and reboots for simply no reason
Nop. Last time I experienced something similar was using a crappy Nokia charger.

However, we need to know which OS flavor/revision you're using in order to help.
the last 2 builds for frodo in this thread, didnt happen when i used gotham either, not raspbmc, the reboot problem only seems to have appeared since october builds
(2013-10-18, 16:43)stuCONNERS Wrote: [ -> ]is anyone experience rebooting issues without anything showing in the logs? Either a bug or my power supply went downhill between updates. im lucky if i can get a couple of hours between reboots. wonderered if it was my overclcock, so went back to 700 from 1150 and still the same, couple of hours and reboots for simply no reason

I had a simlar problem (RBEJ Gotham / Popcornhour Build) where XBMC would restart itself with no warning and occasionally reboot itself. It didn't seem to matter if it was playing a video or idle. This had been happening for a couple of weeks or so.

After enabling logging I noticed that in a couple of occurances that the last thing logged was the OPENELEC.DEVUPDATE addon - which I uninstalled. The RPi has remained stable for the last three days since doing this so it looks like that may be the casue for my problem (no idea why).

(2013-10-18, 16:10)MilhouseVH Wrote: [ -> ]If you want to eliminate the risk of SD card corruption, disable auto-update, boot from /dev/mmcblk0p1 with NFS, SMB or USB used for disk, and then update firmware on the SD card primary partition using only your PC...

Good advice - thanks. I think I will go down this root next time I need to update.
(2013-10-18, 16:10)MilhouseVH Wrote: [ -> ]… boot from /dev/mmcblk0p1 with NFS, SMB or USB used for disk...
Is there a performance hit using NFS as opposed to USB? Raw transfer speed for NFS over fast ethernet (Pi does not have gigabit ethernet) would be slower than USB).
This is what I do for updating... rename config.txt to whatever, copy update files to update folder, reboot, let update finish, rename whatever to config.txt, reboot.
(2013-10-18, 12:38)rbej Wrote: [ -> ]Updated Frodo Branch

- updated OpenElec build

- updated firmware and kernel

- sync with Frodo Popcornmix branch (frodo_rbp_backports)

http://netlir.dk/rbej/builds/

http://lysin.me/rbej

Things to test:
Black screen when switching channels with live tv
Loud noise at start of playback when using amplification
Seek hanging when deinterlace is enabled

You can use the advancedsetting streamsilence (http://wiki.xbmc.org/?title=advancedsettings.xml) to keep hdmi audio active when playback stops.
This should avoid the loss of a couple of seconds of audio at start of playback while receiver locks on, and is useful for music playback.

Hopefully there will be a gotham build too....
Hi Popcornmix,

i hope u can help me

here is the log:
http://xbmclogs.com/show.php?id=70647

I start an HD-Stream and after 1-2 Minutes, the Screen will get frozed for any sec.

I hope you know what i mean ;-)
(2013-10-18, 19:05)allan87 Wrote: [ -> ]
(2013-10-18, 16:10)MilhouseVH Wrote: [ -> ]… boot from /dev/mmcblk0p1 with NFS, SMB or USB used for disk...
Is there a performance hit using NFS as opposed to USB? Raw transfer speed for NFS over fast ethernet (Pi does not have gigabit ethernet) would be slower than USB).

For booting? Not really, you're talking about a 100MB image being loaded into RAM. It might load a couple of seconds faster on USB, but that's it.

Even when OpenELEC is unable to load the SYSTEM image into RAM, accessing the SYSTEM file from a slow SD card is not likely to be noticeably slower than accessing the same file over NFS or USB (thanks to OS file caching). You could put the SYSTEM file on USB, which will then mean auto-update is no longer an option, but I seriously doubt you'll notice any difference in terms of performance between SD, NFS and USB.

Putting /storage on USB is a different matter as generally you want to access your thumbs etc. as quickly as possible, however NFS performance is still pretty good when mounting /storage.
No, I wasn't referring to booting. Booting could take twice as long and I wouldn't care. To be clearer, is there a performance hit using NFS as opposed to USB for storage?
(2013-10-18, 21:17)allan87 Wrote: [ -> ]No, I wasn't referring to booting. Booting could take twice as long and I wouldn't care. To be clearer, is there a performance hit using NFS as opposed to USB for storage?

Yes, of course. NFS is going to be capped at ~11MB/s, USB can hit 25MB/s. However, the real world difference isn't likely to be so significant, but you will - in all probability - see a performance gain from USB over NFS.