Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi Part 2 - 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 Part 2 (/showthread.php?tid=184866)



RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-03-26

(2014-03-26, 16:14)pplucky Wrote: When I started using USB to boot with rbej Frodo builds, I felt additional smoothness in menus (apparent better performance). Does that mean that within these test builds, it won't make not that much difference?

You mean you can tell a difference when switching boot=/dev/mmcblk0p1 to boot=/dev/sda1? It's hard to imagine how that could be when OpenELEC usually loads the SYSTEM image entirely into RAM rendering the performance of the underlying device and partition entirely moot. You could of course be running a 256MB Pi, or a 512MB Pi with 256/256 memory split, in which case SYSTEM won't be loaded into RAM, but even then the difference in performance of menus is unlikely to be significant, assuming it is even noticeable.

If however you're talking about the difference when moving /storage (disk=) from SD to USB, then that is likely to be more noticeable, but it's not what is being discussed here.

The main reason for using USB (or NFS or SMB) as the boot partition was to avoid SD corruption, but as that is now no longer an issue there are no compelling reasons to use anything but boot=/dev/mmcblk0p1. Of course you can carry on using USB/NFS/SMB as your boot partition if you want, provided you are happy to accept the downsides that come with that decision (when using OpenELEC) all for essentially zero upside (there will be little if any performance gain).


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - john.cord - 2014-03-26

System Sounds are only Mono (right channel) since latest nightly ?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - pplucky - 2014-03-26

(2014-03-26, 16:35)MilhouseVH Wrote: If however you're talking about the difference when moving /storage (disk=) from SD to USB, then that is likely to be more noticeable, but it's not what is being discussed here.
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...


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-03-26

(2014-03-26, 18:37)john.cord Wrote: System Sounds are only Mono (right channel) since latest nightly ?

So it is (well I think it's left channel...)


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - spjonez - 2014-03-26

(2014-03-26, 16:35)MilhouseVH Wrote: You could of course be running a 256MB Pi, or a 512MB Pi with 256/256 memory split, in which case SYSTEM won't be loaded into RAM, but even then the difference in performance of menus is unlikely to be significant, assuming it is even noticeable.
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?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - ijsbeer79 - 2014-03-26

Also depends on the player you are using. DVDplayer or OMX?
OMX is less memory consumming.

See also: http://forum.xbmc.org/showthread.php?tid=184866&pid=1626730#pid1626730 and http://forum.xbmc.org/showthread.php?tid=184866&pid=1632331&highlight=memory#pid1632331


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-03-26

(2014-03-26, 23:14)spjonez Wrote:
(2014-03-26, 16:35)MilhouseVH Wrote: You could of course be running a 256MB Pi, or a 512MB Pi with 256/256 memory split, in which case SYSTEM won't be loaded into RAM, but even then the difference in performance of menus is unlikely to be significant, assuming it is even noticeable.
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?

3DSBS doesn't require any more memory than non-3D, and 128M is enough for BluRay quality (level 4.1) 1080p (using omxplayer).
Using dvdplayer, running above level 4.1 H264 (e.g. with lots of reference frames), and increasing fanart/cover image resolution
(and/or using a skin that displays lots of covers at once - e.g. in a wall view) may be reasons for increasing gpu_mem.

Why not try gpu_mem=192. That should allow openelec to cache the system file in RAM and will be enough for almost anything on GPU.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - spjonez - 2014-03-26

(2014-03-26, 23:37)popcornmix Wrote: 3DSBS doesn't require any more memory than non-3D, and 128M is enough for BluRay quality (level 4.1) 1080p (using omxplayer).
Using dvdplayer, running above level 4.1 H264 (e.g. with lots of reference frames), and increasing fanart/cover image resolution
(and/or using a skin that displays lots of covers at once - e.g. in a wall view) may be reasons for increasing gpu_mem.

Why not try gpu_mem=192. That should allow openelec to cache the system file in RAM and will be enough for almost anything on GPU.
Thanks! Set to 192 and tried a few of the more taxing files I have. Everything's working great!


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - allan87 - 2014-03-27

(2014-03-26, 06:54)MilhouseVH Wrote: Includes Python regex package for evaluation purposes. Initial benchmarking indicates generally positive (and in some cases, significant) performance gains. Replace "import re" with "import regex as re" in addons to test effectiveness.
Are you saying that if I (an end user) modify an addon as indicated, it will access the new regex package? If so, is any step required, in addition to editing the code?

Also, I was looking at a particularly slow addon (when running on RPi) which contains "import re" in its code. I noticed that the addon also imports beautifulsoup and elementtree, which themselves contain "import re". Do I assume correctly that, to get the full benefit of the regex package, one would have to modify these addons as well?


Re: RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-03-27

(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.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - pplucky - 2014-03-27

Hello.

Newly installed latest Gotham test build and when trying to check a 3D SBS movie, TV auto-switches properly to 3D mode and back out of it when video playback is stopped.
Still then, external SRT subtitles are not displayed properly and cut half on the right hand side (left part of subtitle) and the remaining on the left hand side (right part of subtitle).

Tried playing around with subtitle settings, but nothing worked to get these subtitles displayed properly. Anyone has any ideas?

Thanks in advance.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-03-27

(2014-03-27, 01:45)pplucky Wrote: Newly installed latest Gotham test build and when trying to check a 3D SBS movie, TV auto-switches properly to 3D mode and back out of it when video playback is stopped.
Still then, external SRT subtitles are not displayed properly and cut half on the right hand side (left part of subtitle) and the remaining on the left hand side (right part of subtitle).

Like this?
http://forum.xbmc.org/showthread.php?tid=176043&pid=1663487#pid1663487


Re: RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-03-27

(2014-03-27, 00:23)allan87 Wrote:
(2014-03-26, 06:54)MilhouseVH Wrote: Includes Python regex package for evaluation purposes. Initial benchmarking indicates generally positive (and in some cases, significant) performance gains. Replace "import re" with "import regex as re" in addons to test effectiveness.
Are you saying that if I (an end user) modify an addon as indicated, it will access the new regex package? If so, is any step required, in addition to editing the code?

Yes, that's what you do, however you need to do it wherever "re" is imported by the addon, which could be in several files depending on the complexity of the addon.

I'll release some code later which may help testing and analysis, and that will require fewer changes to existing addon code (just a change to default.py).

(2014-03-27, 00:23)allan87 Wrote: Also, I was looking at a particularly slow addon (when running on RPi) which contains "import re" in its code. I noticed that the addon also imports beautifulsoup and elementtree, which themselves contain "import re". Do I assume correctly that, to get the full benefit of the regex package, one would have to modify these addons as well?

Ultimately regex may replace re so that all packages (both add-on packages and system packages) use the new regex code. For the purposes of testing regex, I'd probably restrict the changes to addons only.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - pplucky - 2014-03-27

(2014-03-27, 01:51)popcornmix Wrote:
(2014-03-27, 01:45)pplucky Wrote: Newly installed latest Gotham test build and when trying to check a 3D SBS movie, TV auto-switches properly to 3D mode and back out of it when video playback is stopped.
Still then, external SRT subtitles are not displayed properly and cut half on the right hand side (left part of subtitle) and the remaining on the left hand side (right part of subtitle).

Like this?
http://forum.xbmc.org/showthread.php?tid=176043&pid=1663487#pid1663487

Nope, like this:
Image

Correct subtitle should be:
TIM BURTON APRESENTA O
ESTRANHO MUNDO DE JACK

Edit: Don't know if it is relevant, but it behaves the same in omxplayer or DVDplayer.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-03-27

(2014-03-27, 00:23)allan87 Wrote:
(2014-03-26, 06:54)MilhouseVH Wrote: Includes Python regex package for evaluation purposes. Initial benchmarking indicates generally positive (and in some cases, significant) performance gains. Replace "import re" with "import regex as re" in addons to test effectiveness.
Are you saying that if I (an end user) modify an addon as indicated, it will access the new regex package? If so, is any step required, in addition to editing the code?

Also, I was looking at a particularly slow addon (when running on RPi) which contains "import re" in its code. I noticed that the addon also imports beautifulsoup and elementtree, which themselves contain "import re". Do I assume correctly that, to get the full benefit of the regex package, one would have to modify these addons as well?

@allan87: If you're interested in analysing your addons, this post may make life a little easier. Probably best to continue the addon/re/regex discussion there. Smile


This forum uses Lukasz Tkacz MyBB addons.