•   
  • 1
  • 74
  • 75
  • 76(current)
  • 77
  • 78
  • 174
  •   
OpenELEC Testbuilds for RaspberryPi
I've also just had the system halt on me while idle at the XBMC GUI menu but while scp'ing across a new SYSTEM file. The file transfer got to 90%/81MB and then the system halted. The system had been up for 3-4 minutes at this point.
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-29, 02:24)MilhouseVH Wrote: I've also just had the system halt on me while idle at the XBMC GUI menu but while scp'ing across a new SYSTEM file. The file transfer got to 90%/81MB and then the system halted. The system had been up for 3-4 minutes at this point.
But do you think your write file test would have caught this?
(2013-01-29, 02:31)popcornmix Wrote:
(2013-01-29, 02:24)MilhouseVH Wrote: I've also just had the system halt on me while idle at the XBMC GUI menu but while scp'ing across a new SYSTEM file. The file transfer got to 90%/81MB and then the system halted. The system had been up for 3-4 minutes at this point.
But do you think your write file test would have caught this?

Unlikely, as dmesg looked clean prior to the file transfer, but arguably this is a different scenario.

When the Pi is booting and mounting partitions/touching critical files, it is (IMHO) more appropriate to reboot the system if the Pi suspects the SD card is misbehaving, however once the system is up and running it probably shouldn't reboot even if the SD card misbehaves. This opinion only applies to OpenELEC however, as I'm yet to see OpenELEC trash the ext4 partition and critical files except when booting, but other distributions may have different usage patterns where rebooting at any time would be desirable, so the patch may still be useful (though I fear the timeout may occur only after the damage is already done).

Fundamentally though, the SD card shouldn't be misbehaving...
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-29, 01:39)popcornmix Wrote: I don't believe initial_turbo makes corruption more or less likely.

OK, I must have misunderstood what you meant when you said earlier "Either suggest people with sdcard corruption problems avoid initial_turbo, or include a (up to 60 second) delay before updating firmware if initial_turbo is in config.txt."

(2013-01-29, 02:59)doveman2 Wrote: OK, I must have misunderstood what you meant when you said earlier "Either suggest people with sdcard corruption problems avoid initial_turbo, or include a (up to 60 second) delay before updating firmware if initial_turbo is in config.txt."

The suggestion discussed was disabling turbo mode by switching to the conservative performance manager when updating - but that it circumvented when initial_turbo is used.
Some help
I use my RPI connected to a Sony AV amplifier with HDMI cable and the Sony connected to my LG screen with ah HDMI cable..
CEC is activated on all the units, RPI, Sony and LG. The remote sony or Lg is not working on CEC mode.
The RPI connected to the LG , without the sony AV was working fine in CEC mode. The 2 cables are working fine on direct connect RPI to LG led.
During the RPI boot i have the info CEC TV- AV AMP avalable.
Anybody can help me?
Xbmc Frodo 12 is Final !!

http://xbmc.org/natethomas/2013/01/29/xbmc-12-0-frodo/

If you want OpenElec with Frodo Final download from this:

http://forum.xbmc.org/showthread.php?tid...pid1314260



Just wondering if anyone with a stable Pi has tried the modified kernel (stock 720p GUI) with anti-SD card corruption hack (latest build available here, including Popcornmix's sdhci patch [halt] enabled with sdhci-bcm2708.reboot_fatal=Y).

While it is by no means the perfect solution, it would be useful to know if it has any positive or negative effect so that a better solution can be found (other than eliminating SD card timing problems entirely, of course).
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.
I have a Sony str Dh520, doesn't work either. According to me this sony didn't implemented CEC fully.

(2013-01-29, 17:11)yantoucan Wrote: Some help
I use my RPI connected to a Sony AV amplifier with HDMI cable and the Sony connected to my LG screen with ah HDMI cable..
CEC is activated on all the units, RPI, Sony and LG. The remote sony or Lg is not working on CEC mode.
The RPI connected to the LG , without the sony AV was working fine in CEC mode. The 2 cables are working fine on direct connect RPI to LG led.
During the RPI boot i have the info CEC TV- AV AMP avalable.
Anybody can help me?

(2013-01-29, 21:17)brinka123 Wrote: I have a Sony str Dh520, doesn't work either. According to me this sony didn't implemented CEC fully.

(2013-01-29, 17:11)yantoucan Wrote: Some help
I use my RPI connected to a Sony AV amplifier with HDMI cable and the Sony connected to my LG screen with ah HDMI cable..
CEC is activated on all the units, RPI, Sony and LG. The remote sony or Lg is not working on CEC mode.
The RPI connected to the LG , without the sony AV was working fine in CEC mode. The 2 cables are working fine on direct connect RPI to LG led.
During the RPI boot i have the info CEC TV- AV AMP avalable.
Anybody can help me?

OK everything is working now.
I need to use the LG remote. In fact I use an universal remote and i have to select TV to use the LG CEC. The Sony remote or selecting the AV SONY on the universal remote has no effect in CEC.

The name of Xbmc 13 is Gotham. (Too much Batman movies Wink )




(2013-01-22, 20:22)Alex131089 Wrote: Are you aware of any problem with ASS subtitles ?
[..]
Sorry, but nobody ? Rolleyes
(2013-01-29, 18:53)MilhouseVH Wrote: Just wondering if anyone with a stable Pi has tried the modified kernel (stock 720p GUI) with anti-SD card corruption hack (latest build available here, including Popcornmix's sdhci patch [halt] enabled with sdhci-bcm2708.reboot_fatal=Y).

Stable, yes and no. I have problematic 512mb. It will destroy partition every reboot with overclock. But can handle overclocking and run stable with ext4 on usb.

I tested with r12969 official.

Initial boot the gui didnt properly load, loaded blue background, gui came back for a bit but disappeared as soon as I started navigating. I turned it off and on, the Ext 4 partition was toast.

Second attempt, gui failed to load again, turned off and on, the checker caught it and rebooted it before splash screen, but after reboot Ext 4 partition was corrupted.

(I did a third test with no overclock and without patched kernal because it was a new SD card and I didnt want to give you a bum steer, it booted fine, no gui problems and rebooted without corruption.)

-----

Is there any reason I should see worse SMB performance streaming between r12669 (1080p ver) and r12969?

Every time I think I have build thats working, it will work for a week or so but then buffering will come back to haunt me again. (I have isolated everything in the network when it happens. Its the same files too that have been playing fine suddenly start buffering)


(2013-01-31, 04:52)Wanderlei Wrote: Stable, yes and no. I have problematic 512mb. It will destroy partition every reboot with overclock. But can handle overclocking and run stable with ext4 on usb.

Thanks so much for the feedback, although I'm afraid I think you have what I would call a "lemon" - a Pi that can't overclock at all without corrupting the SD card, and probably not a suitable candidate for this test/hack (I had one of those too but gave it away). The hack is mainly for those users with Pi that *can* overclock and use their SD card normally, but experience only occasional SD card partition corruption when booting (due to the SD card not initialising correctly on boot).

However, for those using USB/NFS for /storage rather than SD ext4 (such as yourself) the hack should still prove useful as it will prevent the Pi from corrupting its boot files should OpenELEC go on to perform an auto-update, so it might be worth testing auto-update with/without the hack (disable with iotimeout=0 in cmdline.txt). You'll also need a KERNEL.md5 file in /storage/.update as follows (I'll include the md5 on my webspace in future: KERNEL and KERNEL.md5):

Code:
<md5sum> target/KERNEL

One other addition in the modified kernel is Popcornmix's patch, if you enable it with sdhci-bcm2708.reboot_fatal=Y does your Pi hang while in XBMC? It's possible this is the point when corruption of your SD card is taking place.
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.
Can't the system overwrite user settings and disable OC if System, Kernel and md5 files are found in the update folder?
It would require an extra reboot to enable user setting after 1st update boot I believe...
 
  • Intel NUC Kit DN2820FYKH ~ Crucial DDR3L SO-DIMM 4GB ~ SanDisk ReadyCache 32GB SSD ~ Microsoft MCE model 1039 RC6 remote
  •   
  • 1
  • 74
  • 75
  • 76(current)
  • 77
  • 78
  • 174
  •   



Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi12
This forum uses Lukasz Tkacz MyBB addons.