Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166)
+---- Thread: OpenELEC Testbuilds for RaspberryPi (/showthread.php?tid=140518)



RE: OpenELEC Testbuilds for RaspberryPi - doveman2 - 2013-03-05

(2013-03-05, 00:49)MilhouseVH Wrote: No, it won't, that's why I've been banging on about updating firmware too! ;-)

Once you have updated your SD card with the rbej kernel (which includes a working NFS/SMB/USB auto-update process - do NOT attempt to auto-update NFS/SMB/USB systems when booting with the stock kernel) you should drop the rbej SYSTEM+KERNEL+MD5 files in your Update/.update folder and reboot, and the rbej auto-update process will update your firmware too.

If you suffer from corrupted SD cards, even while booting from NFS, then enable the "media check" feature to avoid corrupt firmware/kernel.img being written to your SD card (add iotimeout=5000 in cmdline.txt).

Yep, same folder. Just include the two MD5 files long with KERNEL and SYSTEM (total of four files), and once they are there you can reboot the Pi and the files will be extracted and applied to your system (firmware and kernel being written to SD card, SYSTEM to NFS).

Cool, thanks. I thought there must be a reason someone hadn't suggested doing it my way already Wink

I've not suffered any SD corruption yet (touch wood) but I've enabled the "media check" thanks, just to be safe.

EDIT: Awesome! Now I've updated properly, no more audio pops Smile

I have another problem with audio levels however. I haven't tested enough previously to know if it's always been like this. When I play Movies it's very quiet but when I stream from iPlayer it's quite loud/normal, although that varies as Mayday episode 1 is loud/normal whilst The Sorcerers Apprentice is very quiet like my Movies. This is a film rather than a TV Programme so maybe that's relevant but I'm not sure if iPlayer content is all stereo or if some things have multi-channel audio. I tried enabling the Boost Volume on Downmix option but that hasn't made any difference. Playing Recorded TV is quiet as well. I know the RPi analog output is relatively quiet anyway but if one programme can be loud enough I'd think everything else should be able to reach the same volume.

I also have a problem with LiveTV. Before my semi-upgrade (i.e. without doing the firmware) XBMC restarted whenever I selected a channel. After my semi-upgrade, it started working and I could watch TV. After the full upgrade (i.e. including the firmware) it's gone back to restarting XBMC every time. I can play Recorded TV fine, so it's obviously not a GPU/codec issue. I'm using the Mediaportal PVR client addon. This worked on Raspbmc when I tested (although that had it's own problems, such as rebooting whenever I tried to stream from 4oD or ITV player, both of which work fine on OpenElec). It may well just have been a co-incidence that it started working in between upgrades. I'd love to capture some logs to upload but as they're overwritten each time XBMC reboots I'm not sure that I can.

EDIT2: Poweroff (from the Shutdown menu) is a bit hit and miss for me as well. Sometimes it just restarts XBMC.

EDIT3: The volume problem may be because iPlayer "normalises" the volume on it's programmes (but maybe not on Movies it lists, such as The Sorcerer's Apprentice), which makes sense as I recall it being loud when I used it on MediaPortal. So I guess I'm hoping that some way to "normalise" everything will be added to XBMC/RPi so that I can hear everything without having to crank the volume, risking deafening myself/damaging my speakers when using iPlayer or other equipment with my amp.


RE: OpenELEC Testbuilds for RaspberryPi - rbej - 2013-03-05

Updated Frodo Branch

- update firmware (Avoid resetting buffer count to 1 on video_decode output, Fix for alsa hang when starting output of buffer larger than audioplus buffer)

- fix Airplay (tested on Ipad 2)

- fix high cpu usage in System Information

http://forum.xbmc.org/showthread.php?tid=140518&pid=1350100#pid1350100


RE: OpenELEC Testbuilds for RaspberryPi - mcarni - 2013-03-05

Quote:If you suffer from corrupted SD cards, even while booting from NFS, then enable the "media check" feature to avoid corrupt firmware/kernel.img being written to your SD card (add iotimeout=5000 in cmdline.txt).

I believe I am starting to experience what it seems to me as "corrupted SD" problems, it started when I updated with one of Rbej's latest releases.(absolutely no fault on Rbej's releases... just coincidence)
Boot and disk are on an NFS share, so I did a manual update (copied SYSTEM, kernel and firmware...) which went fine.
The only problem is that after the first shutdown there was no way to reboot openelec.
I just got a missing signal on the TV and no sign of life on the pi, only the red power led (no rainbow screen etc)

I tried to remove all the overclocking settings, revert to one of the official openelec releases, change power adapter, but still no luck.
After a poweroff the only way I had to get the pi to boot again was to remove the SD from the pi and re-run ./create_sdcard from a linux box.
But this lasted only for one boot, at thw next reboot I had the same problem.

I swapped the sd card with a new one (same config.tx with overclocking, same NFS boot settings) and so far I rebooted several times with no problem at all.


I am not really sure what my problem is, so I really hope some of you guys could help me out a little:
- is this how a "corrupted SD" problem shows up? or simply this is what happens when the SD card fails due to bad luck, manufacture problem age...etc.? (4 months old Sandisk 4Gb, nothing fancy but working fine as a storage device on laptop camera etc.)
- is there a way to uncorrupt the SD card?
- are "media check" and "iotimeout" something that prevent corrupting SD cards? could you give me a link on where to get mor einfo on these options?
- is there any setting that is more "SD corruption" prone? or is there any factor that i shoudl take into account (just trying to avoid buying 1 SD card every 4 months...)


Thank you very much

m


RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-03-05

(2013-03-05, 11:19)mcarni Wrote: I believe I am starting to experience what it seems to me as "corrupted SD" problems, it started when I updated with one of Rbej's latest releases.(absolutely no fault on Rbej's releases... just coincidence)
Boot and disk are on an NFS share, so I did a manual update (copied SYSTEM, kernel and firmware...) which went fine.
The only problem is that after the first shutdown there was no way to reboot openelec.
I just got a missing signal on the TV and no sign of life on the pi, only the red power led (no rainbow screen etc)

I tried to remove all the overclocking settings, revert to one of the official openelec releases, change power adapter, but still no luck.
After a poweroff the only way I had to get the pi to boot again was to remove the SD from the pi and re-run ./create_sdcard from a linux box.
But this lasted only for one boot, at thw next reboot I had the same problem.

I swapped the sd card with a new one (same config.tx with overclocking, same NFS boot settings) and so far I rebooted several times with no problem at all.


I am not really sure what my problem is, so I really hope some of you guys could help me out a little:
- is this how a "corrupted SD" problem shows up? or simply this is what happens when the SD card fails due to bad luck, manufacture problem age...etc.? (4 months old Sandisk 4Gb, nothing fancy but working fine as a storage device on laptop camera etc.)
- is there a way to uncorrupt the SD card?
- are "media check" and "iotimeout" something that prevent corrupting SD cards? could you give me a link on where to get mor einfo on these options?
- is there any setting that is more "SD corruption" prone? or is there any factor that i shoudl take into account (just trying to avoid buying 1 SD card every 4 months...)


Thank you very much

m

Yes, sounds like corrupted boot files - you don't get the rainbow screen, just a completely dead Pi. When you did your manual update, did you copy the files using a PC or just your Pi and SSH (or maybe SFTP)? Did the transfer to SD card seem unusually slow, or not?

The recovery method is to extract the firmware and kernel.img, then write those files to the root of the SD card using a PC and card reader. After that, your Pi should come back up, no need to restore or recreate the entire image.

I don't think the corruption is indicative of a failing SD card, it's just something that can happen with the current firmware and certain SD cards, particularly if you are overclocking your Pi. For some users it happens fairly regularly, for others once in a blue moon, and for the lucky, never at all.

The "media check" feature (enabled by adding iotimeout=5000 to the end of your kernel line in cmdline.txt) is an attempt to detect problems early in the boot sequence and avoid using an SD card that has not been initialised correctly - the likely reason why you ended up with corrupt files - by automatically rebooting the Pi until the SD card HAS initialised correctly.

So just go ahead, edit cmdline.txt in a text editor and append "iotimeout=5000" to the end of your kernel parameters. Under normal circumstances you'll not notice anything unusual in the boot sequence, but if/when your SD card is misbehaving you'll notice a delay of up to 30 seconds, an an automatic reboot. 30 seconds may sound like a long time, but it's shorter than the time it would take to recover your system... ;-)

If only you'd enabled media check before updating you could be letting me know whether it had actually worked as intended, or not... and you'd probably still have a working system!

Overclocking is likely to increase the chance of corruption, but permanent SD card damage is very unlikely.


RE: OpenELEC Testbuilds for RaspberryPi - doveman2 - 2013-03-05

Is the KERNEL file a compressed file that contains both kernel.img and the firmware then? If so, I'm wondering if I can extract them both and put them on the SD card manually? What file(s) are the firmware once extracted?


RE: OpenELEC Testbuilds for RaspberryPi - mcarni - 2013-03-05

Quote:When you did your manual update, did you copy the files using a PC or just your Pi and SSH (or maybe SFTP)? Did the transfer to SD card seem unusually slow, or not?
I generally scp the kernel plus the firmware to the openelec machine and kernel/SYSTEM plus firmware to the nfs server.
Unfortunately i didn't pay attention to how long it took to copy the files over... I must have gone for a cup of tea.... while doing it....sorry...


Quote:I don't think the corruption is indicative of a failing SD card, it's just something that can happen with the current firmware and certain SD cards, particularly if you are overclocking your Pi. For some users it happens fairly regularly, for others once in a blue moon, and for the lucky, never at all.
sorry, probably it was just me just being paranoid since it never happend to me and then it started all of a sudden several times in a row

Quote:So just go ahead, edit cmdline.txt in a text editor and append "iotimeout=5000" to the end of your kernel parameters. Under normal circumstances you'll not notice anything unusual in the boot sequence, but if/when your SD card is misbehaving you'll notice a delay of up to 30 seconds, an an automatic reboot. 30 seconds may sound like a long time, but it's shorter than the time it would take to recover your system... ;-)
I will definitively do that. 30 seconds? no problem, just the time to turn the kettle on....or grab a beer...

Thanks a lot for your help,

M


RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-03-05

(2013-03-05, 12:54)doveman2 Wrote: Is the KERNEL file a compressed file that contains both kernel.img and the firmware then? If so, I'm wondering if I can extract them both and put them on the SD card manually? What file(s) are the firmware once extracted?

No, the firmware is in the SYSTEM file, which is a compressed file system.

During the update process, the new kernel is copied to the SD card (overwriting the old kernel), the SYSTEM file copied to wherever it needs to go, then the firmware is extracted from the new SYSTEM file and written to SD card.

The firmware files are bootcode.bin, start.elf and fixup.dat. You can also find them in the ZIP package in the 3rdparty folder.


RE: OpenELEC Testbuilds for RaspberryPi - doveman2 - 2013-03-05

(2013-03-05, 13:00)MilhouseVH Wrote: No, the firmware is in the SYSTEM file, which is a compressed file system.

During the update process, the new kernel is copied to the SD card (overwriting the old kernel), the SYSTEM file copied to wherever it needs to go, then the firmware is extracted from the new SYSTEM file and written to SD card.

The firmware files are bootcode.bin, start.elf and fixup.dat. You can also find them in the ZIP package in the 3rdparty folder.

OK, thanks. I saw those files in the 3rdparty folder but wasn't sure if they were the latest ones.

So does that mean I can't just copy SYSTEM to wherever I have it (NFS folder or SD card) or will it be OK even though it contains the firmware?

Hmm weird. The volume seems to be OK today and the Downmix option is working and having a noticeable effect on the volume. LiveTV is working as well at the moment Smile

It's not all hunky-dory though as I can't connect with WinSCP or Putty now. System Info is showing it's on 192.168.1.68 and my router agrees (although it said 192.168.1.69 a minute ago) but I just get "Network error: Connection refused" from Putty. The Web interface works fine as does playing Movies from my LAN. I checked the OE settings and SSH Server is enabled.


RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-03-05

(2013-03-05, 13:37)doveman2 Wrote: So does that mean I can't just copy SYSTEM to wherever I have it (NFS folder or SD card) or will it be OK even though it contains the firmware?

The firmware will only be extracted from the SYSTEM file if you drop the SYSTEM file into the Update folder (along with KERNEL and MD5x2).

If you are updating manually, then you will need to copy the firmware files from the 3rdparty folder to your SD card, along with the new kernel.img. And update the SYSTEM file in your NFS-mounted /system folder.

Though if you have already switched to the Rbej builds you can just use the Update-folder method as his build has support for NFS/SMB/USB users. Since you are booting over NFS, just copy the SYSTEM+KERNEL+MD5 files to the /storage/.xbmc/.update folder on your NAS and reboot the Pi which will find and apply the update.

I would advise that you enable the media check feature just in case your Pi decides it's a good time to trash the SD card... Smile


RE: OpenELEC Testbuilds for RaspberryPi - doveman2 - 2013-03-05

(2013-03-05, 13:47)MilhouseVH Wrote:
(2013-03-05, 13:37)doveman2 Wrote: So does that mean I can't just copy SYSTEM to wherever I have it (NFS folder or SD card) or will it be OK even though it contains the firmware?

The firmware will only be extracted from the SYSTEM file if you drop the SYSTEM file into the Update folder (along with KERNEL and MD5x2).

If you are updating manually, then you will need to copy the firmware files from the 3rdparty folder to your SD card, along with the new kernel.img. And update the SYSTEM file in your NFS-mounted /system folder.

Though if you have already switched to the Rbej builds you can just use the Update-folder method as his build has support for NFS/SMB/USB users. Since you are booting over NFS, just copy the SYSTEM+KERNEL+MD5 files to the /storage/.xbmc/.update folder on your NAS and reboot the Pi which will find and apply the update.

I would advise that you enable the media check feature just in case your Pi decides it's a good time to trash the SD card... Smile

OK, cool. I use the Update-folder method but sometimes if I don't have the RPi already booted it's quicker to just copy the files to the SD and NFS folder before switching it on.

I'm already using the media check feature as well thanks.


RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-03-05

(2013-03-05, 14:36)doveman2 Wrote: OK, cool. I use the Update-folder method but sometimes if I don't have the RPi already booted it's quicker to just copy the files to the SD and NFS folder before switching it on.

You can prepare the Pi for updating by dropping all 4 update files into the NFS ".update" folder, even while the Pi is switched off - much easier! Smile

(2013-03-05, 14:36)doveman2 Wrote: I'm already using the media check feature as well thanks.

I'd be interested to hear how you get on, particularly if it kicks in successfully, and how long your delay is.


RE: OpenELEC Testbuilds for RaspberryPi - LehighBri - 2013-03-05

(2013-03-05, 11:15)rbej Wrote: - fix Airplay (tested on Ipad 2)

I just saw this... what changed/was fixed with airplay? Also, I just noticed this new PR#2372... any changes/improvements we should expect with that or not really?


RE: OpenELEC Testbuilds for RaspberryPi - doveman2 - 2013-03-05

I tried pinging the Pi on 192.168.1.68 but got General Failure so thought perhaps my router needed rebooting. After doing that, ping worked once and then failed again on the second attempt except for one try. On the third attempt, three out of the four tries worked.

Pinging 192.168.1.68 with 32 bytes of data:
Reply from 192.168.1.68: bytes=32 time<1ms TTL=64
Reply from 192.168.1.68: bytes=32 time<1ms TTL=64
Reply from 192.168.1.68: bytes=32 time<1ms TTL=64
Reply from 192.168.1.68: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.1.68:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

Pinging 192.168.1.68 with 32 bytes of data:
General failure.
General failure.
General failure.
Reply from 192.168.1.68: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.1.68:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

Pinging 192.168.1.68 with 32 bytes of data:
General failure.
Reply from 192.168.1.68: bytes=32 time<1ms TTL=64
Reply from 192.168.1.68: bytes=32 time<1ms TTL=64
Reply from 192.168.1.68: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.1.68:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms


RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-03-05

Wired or WiFi?


RE: OpenELEC Testbuilds for RaspberryPi - doveman2 - 2013-03-05

Wired. Just tested with Raspbmc and SSH works OK on that on 192.168.1.66 (DHCP).