Kodi Community Forum

Full Version: OpenELEC Testbuilds for RaspberryPi
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
@rbej @MilhouseVH

So you still believe bigbuffer patch is problematic? It seems hard to see why it would cause failures.
The only problem I've noticed is that live streams (eg. Flash streams via SportsDevil) have a black screen at start which is fixed by pause/unpause.
(2013-02-27, 20:15)MilhouseVH Wrote: [ -> ]The only problem I've noticed is that live streams (eg. Flash streams via SportsDevil) have a black screen at start which is fixed by pause/unpause.

And you see that with just bigbuffer patch? No other patches applied?
(2013-02-27, 20:15)MilhouseVH Wrote: [ -> ]The only problem I've noticed is that live streams (eg. Flash streams via SportsDevil) have a black screen at start which is fixed by pause/unpause.

Me to.

Black screen when play online movie

http://pastebin.com/9BxU09Sa

Black sceen after seek online movie (remote control)

http://pastebin.com/D2T4LYRt

But this is new scheme buffering and stalling issues, not bigbuffer patch. I apply only new scheme patch and random black screen when play online movie and seek still exist.
(2013-02-27, 20:39)rbej Wrote: [ -> ]Me to.

Black screen when play movie

http://pastebin.com/9BxU09Sa

Black sceen after seek (remote control)

http://pastebin.com/D2T4LYRt

But this is new scheme buffering and stalling issue, not bigbuffer patch.

I'm aware of new_stall hang. I want to know if bigbuffer on its own is safe to submit to xbmc.
(2013-02-27, 17:43)MilhouseVH Wrote: [ -> ]
(2013-02-27, 10:55)pplucky Wrote: [ -> ]Yesterday I was updating from a kernel with this feature already to a new one and I just did what you proposed: simply dropping the above mentioned files in the Update folder (my config.txt was not changed, meaning it had OC settings on)...but it didn't work out well.

After the first reboot (when the update is to be carried out), the update process took much longer than it normally does but it completed. When it restarted automatically, it was no longer possible to boot (stuck in colorful Pi startup screen). I took the SD card out, suspecting that SYSTEM partition had been corrupted (like it used to happen when updating with overclock on), but it wasn't... Still then, the Pi didn't boot at all.

I had to reinstall the SD card with the fresh install procedure (from the same rbej build image and then delete and recreate the STORAGE partition in SD card (I now use it to keep other files). After this, my Pi came back to life with everything updated...

Any clue of what may have happened or can I provide any insight to help figure this out? Or did I misunderstood the purpose of this patch?

So to be clear, did you have "iotimeout=5000" added to the end of your kernel parameters in cmdline.txt, when your update failed? By default the media check feature is disabled, so without adding this extra parameter the feature will not be operating.
No, actually I saw that comment of yours, but did not understand it was required. Will try next time.

(2013-02-27, 17:43)MilhouseVH Wrote: [ -> ]From what you say it sounds like you experienced a classic case of the SD card not being correctly initialised, leading to corrupt boot files caused by the update. The long delay you experienced is what the "media check" is intended to detect (slow write performance due to mmc0 timeouts) so I'm surmising that you did not have the media check feature enabled when you performed your update.

Many thanks for the feedback, but for my own peace of mind it would be good if you can confirm if you had media check enabled or not. And at least I now know I'm not the only person with a system capable of causing this kind of boot file corruption, though it's not something that has been a problem for me since I created media check!. Smile
No worries, no need to thank. Still then, I'm pretty sure I had nothing changed on cmdline.txt
By the way, this timeout in cmdline.txt does not affect normal boots, does it? How does this work, just for my understanding?

(2013-02-27, 17:43)MilhouseVH Wrote: [ -> ]Note that in future should this happen again, you don't have to reinstall the SD card you only need to replace your kernel.img/bootcode.bin/fixup.dat/start.elf files in the FAT partition with uncorrupted versions.
OK, good to know that.
I'm using r13369... is anyone having any audio/video sync issues? It seems like on all of my videos now that the audio and video is out of sync (it starts in sync but gets out of sync pretty quickly within a handful of seconds).
(2013-02-27, 20:42)popcornmix Wrote: [ -> ]
(2013-02-27, 20:39)rbej Wrote: [ -> ]Me to.

Black screen when play movie

http://pastebin.com/9BxU09Sa

Black sceen after seek (remote control)

http://pastebin.com/D2T4LYRt

But this is new scheme buffering and stalling issue, not bigbuffer patch.

I'm aware of new_stall hang. I want to know if bigbuffer on its own is safe to submit to xbmc.

Working fine, but too long open net stream. Sometimes not open.
I've just tested Raspbmc and LiveTV works fine on that, so I guess it must be something about OE that doesn't get along with the Mediaportal PVR addon.
(2013-02-27, 20:19)popcornmix Wrote: [ -> ]
(2013-02-27, 20:15)MilhouseVH Wrote: [ -> ]The only problem I've noticed is that live streams (eg. Flash streams via SportsDevil) have a black screen at start which is fixed by pause/unpause.

And you see that with just bigbuffer patch? No other patches applied?

Ah no, it was with other patches. I'll test it with just the bigbuffer patch (then work through the other patches) and get back to you once I've identified which is the cause.
(2013-02-27, 21:05)pplucky Wrote: [ -> ]By the way, this timeout in cmdline.txt does not affect normal boots, does it? How does this work, just for my understanding?

The "media check" feature (when enabled) will time how long it takes to write a 1MB file to the SD card early in the startup sequence before any partitions are mounted.

Under normal circumstances it should take less than 200ms to write the file so you shouldn't notice any extra delay in the boot sequence. However, when the SD card hasn't initialised properly it will take a lot longer - in my tests, in the region of 30-35 seconds - to write the file and so the Pi will reboot whenever the time taken exceeds the value of iotimeout. You specify this value in cmdline.txt, a value of 0 (or omitting the parameter) disables the feature entirely, a value of 5000 is normally sufficient.

Only when the Pi successfully writes the file without any significant delay will the boot sequence continue. From my testing, an incorrectly initialised SD card is the main cause of ext4 (/dev/mmcblk0p2) partition corruption, and as you found, also file corruption due to system updates.

Personally, I think it's worth the occasional 30 second+reboot delay than to have to restore my entire system (due to ext4 corruption) or waste time resurrecting a non-bootable system after applying an update!

Though I'll make no bones about this, it's a total hack, as you need to write a file to the SD card to provoke the mmc0 timeouts and the only way to detect the presence of the timeout without waiting an unreasonable amount of time for errors to appear in the log, is to time how long it takes to write the file.

However in my numerous tests, this hack has eliminated partition and file corruption on my system. Maybe it will be possible to use a smaller file in future which will reduce the amount of time taken to detect when the SD card is not correctly initialised (eg. a 250KB file may take no more than 10 seconds) but this requires more feedback from people testing this feature - I'll need to know the elapsed time reported on your systems when the delay is detected to determine an optimum size.

Obviously, the ideal solution is to eliminate the cause of the failure to initialise the SD card but that may take a while longer so consider this only a temporary stop-gap measure, and I doubt it will be included in stock OE builds anyway.
(2013-02-27, 21:57)MilhouseVH Wrote: [ -> ]
(2013-02-27, 20:19)popcornmix Wrote: [ -> ]
(2013-02-27, 20:15)MilhouseVH Wrote: [ -> ]The only problem I've noticed is that live streams (eg. Flash streams via SportsDevil) have a black screen at start which is fixed by pause/unpause.

And you see that with just bigbuffer patch? No other patches applied?

Ah no, it was with other patches. I'll test it with just the bigbuffer patch (then work through the other patches) and get back to you once I've identified which is the cause.

Argghh... so frustrating, I can't reproduce it now - and having pulled in the latest updates from the OE repository earlier today many of the patches no longer apply... I have tested with both big buffer and hdmi/analog output patches (the only patches that apply cleanly) and no problems so far.
"Add Both HDMI and analog audio output" doesn't seem to work well. When I set audio output to "all", I'm unable to seek in mkv movies anymore, neither with the arrow keys, nor by typing the minutes and seconds in. No problems with settings "HDMI" and "analog". I've tested it latest rbej build (r13376) and only with mkv.
(2013-02-28, 01:46)hpbaxxter Wrote: [ -> ]"Add Both HDMI and analog audio output" doesn't seem to work well. When I set audio output to "all", I'm unable to seek in mkv movies anymore, neither with the arrow keys, nor by typing the minutes and seconds in. No problems with settings "HDMI" and "analog". I've tested it latest rbej build (r13376) and only with mkv.

Confirm. I raported this bug to author this patch.

(2013-02-27, 12:53)popcornmix Wrote: [ -> ]
(2013-02-27, 09:01)rbej Wrote: [ -> ]- CEC 2.1.0 with many fixes for Rpi

Please report on whether this build is working for CEC as there are some changes with how CEC handles state changes.
Can you check if CEC remote control works initially.
Whether it handles HDMI mode changes (e.g. the automatic switching to 1080p24 when playing a video file and back again).
Whether it handles switching channel away from Pi and back.
Whether it handles switching off the TV and switching back on.

Working perfect. Much better response that 2.0.5.
Remove "Add Both HDMI and analog audio output" patch resolved problem with black screen when seek online movie with new scheme buffering patch. But still random black screen when play online movie exist.