OpenELEC Testbuilds for RaspberryPi Part 2
(2014-03-26, 18:42)pplucky Wrote: Sorry for the confusion, but that was what I meant (storage partition in USB rather than SD), that is disk=/dev/sda1 rather than disk=/dev/mmcblk0p2.

Does the update process by dropping tar file in update folder, work in this setup? I remember having issues before (SD card SYSTEM partition corruption), with dropping SYSTEM and KERNEL in the same folder...

As long as you have boot=/dev/mmcblk0p1 the tar update process will work reliably*, and the update process doesn't care what your disk= is set to - it's only boot= that matters.

SD corruption problems were fixed back in November.

* I've just checked the update process code and it will in fact still permit an update when boot= is using a USB partition (/dev/sdaX, LABEL or UUID) - it only explicitly disables updating when CIFS/NFS/SMB/ISCSI/NBD are being used as the boot partition. However a Pi that is using a USB partition for boot= is then likely to have its firmware files copied to the USB partition rather than /dev/mmcblk0p1 (SD card partition) which is where they need to go, so even though it's permitted, it's not going to work reliably and should be avoided.

(2014-03-26, 23:14)spjonez Wrote: I've always wondered about this. I'm using 512mb Pi's all with a 256/256 split, my presumption was anything less was not enough for 1080p 3DSBS files (~20gb). It's been quite a while since I've tested lower splits. Do you have a recommended split that will allow the system to be fully loaded into RAM?

OpenELEC will only load SYSTEM into RAM if there is at least 364MB of physical RAM available. 512 - 364 => 148, give or take a few megabytes, so set a maximum of 128 for GPU if you want SYSTEM loaded into RAM. The RAM storage will consume 115-120MB of physical RAM (a figure that is slowly but surely increasing), leaving you with approximately the same physical free RAM as a 256/256 split, and an imperceptible performance difference.

IMHO loading SYSTEM into RAM is not worth it as in many ways it leaves you worse off with reduced free RAM and/or gpu_mem, and the supposed performance gain of having SYSTEM in RAM is very slight, if it is noticeable at all (I can't tell any difference).

My advice is gpu_mem=128 in config.txt (or 180+ if using high resolution image/fanart in advancedsettings.xml), with "noram" added in cmdline.txt to prevent SYSTEM being loaded into RAM, even when there is enough free RAM available. This should ensure there is far more free RAM available to XBMC and Linux for things like buffering and avoiding out of memory situations.
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.


Messages In This Thread
Re: RE: OpenELEC Testbuilds for RaspberryPi Part 2 - by Milhouse - 2014-03-27, 01:44
AW: RE: - by DieterLumpen - 2013-07-29, 20:50
include guires switch? - by hpbaxxter - 2013-08-01, 21:46
RE: dual audio?? - by pootler - 2013-08-03, 17:13
Help, watch 3D Film on Non 3D TV - by unix72 - 2013-08-09, 12:39
Remote Controllers - by tfft - 2013-08-14, 09:11
rbej repeatable crash - by RichG - 2013-08-19, 12:43
New Tester - by theneverstill - 2013-10-03, 17:16
[split] missing subtitle stream - by Jönke - 2014-01-08, 21:03
3D Support - by michbeck100 - 2014-01-11, 01:01
No sound on Gotham builds - by URBANsUNITED - 2014-01-13, 15:19
Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 223