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 - sraue - 2013-11-17

(2013-11-17, 01:55)doveman2 Wrote: Ah thanks, probably they got lost when I copied them across to my PC and then back to the USB with WinSCP. What would be the proper way to copy files across without having to put them on the PC as an intermediary step and thus lose the permissions?

I guess I'll have to edit the cmdline.txt on the SD card to boot from SD again so that I can go in and edit the permissions on the USB files.

you dont need (you should not) copy the .cache (/storage/.cache) folder, all the contents will be recreated on first build (or created on setup some OS related settings (enable/disable services, network, bluetooth)) at least .config/ssh (/storage/.cache/ssh) you never should restore.


Re: RE: OpenELEC Testbuilds for RaspberryPi Part 2 - f1vefour - 2013-11-17

(2013-11-17, 01:55)doveman2 Wrote: Ah thanks, probably they got lost when I copied them across to my PC and then back to the USB with WinSCP. What would be the proper way to copy files across without having to put them on the PC as an intermediary step and thus lose the permissions?

I guess I'll have to edit the cmdline.txt on the SD card to boot from SD again so that I can go in and edit the permissions on the USB files.

Either tar them up or use rsync is your best bet.

Compress:

Code:
tar cvpfz /target.tar.gz /sourcedir/

Decompress:

Code:
tar xvpfz /destdir/



RE: OpenELEC Testbuilds for RaspberryPi Part 2 - wizzard72 - 2013-11-17

(2013-11-14, 18:42)MilhouseVH Wrote:
(2013-11-14, 14:59)Koloss Wrote: Popcornmix or milhouse, can give us a new gotham build with newclock3 patch and airplay fix?

Here you go: Dropbox.

It's standard OpenELEC master plus newclock3 patches. I have no idea about any Airplay fix - unless it's been pushed upstream it's not in this build.

Thanks for the build. It's very fast. The only problem I have is that the subtitle downloader doesn't work. I think they are renewing it, but can't find the location to configure it. Anyone else having this issue?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-11-17

(2013-11-17, 02:00)sraue Wrote: you dont need (you should not) copy the .cache (/storage/.cache) folder, all the contents will be recreated on first build (or created on setup some OS related settings (enable/disable services, network, bluetooth)) at least .config/ssh (/storage/.cache/ssh) you never should restore.

Ah OK, that will be easier than worrying about preserving the permissions then, I'll just delete the .cache folder and let it recreate it, thanks.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-11-17

(2013-11-14, 18:42)MilhouseVH Wrote: Here you go: Dropbox.

It's standard OpenELEC master plus newclock3 patches. I have no idea about any Airplay fix - unless it's been pushed upstream it's not in this build.

LiveTV (tvheadend) still keeps freezing and crashing the RPi for me with this build unfortunately. I've disabled my overclock now though, so I'll test and see if it still happens.

Sometimes it would just stop for a while but the debug OSD was still working so I knew the RPi hadn't crashed and then it would start playing again but it was now obviously behind the realtime signal, so it would do wierd little speed ups to try and catch up and the picture would break up and it never got back in sync anyway and I had to stop and restart the channel. Other times though, it just freezes and completely locks up the RPi, requiring a hard reset.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - schub - 2013-11-17

(2013-11-17, 17:37)doveman2 Wrote:
(2013-11-14, 18:42)MilhouseVH Wrote: Here you go: Dropbox.

It's standard OpenELEC master plus newclock3 patches. I have no idea about any Airplay fix - unless it's been pushed upstream it's not in this build.

LiveTV (tvheadend) still keeps freezing and crashing the RPi for me with this build unfortunately. I've disabled my overclock now though, so I'll test and see if it still happens.

Sometimes it would just stop for a while but the debug OSD was still working so I knew the RPi hadn't crashed and then it would start playing again but it was now obviously behind the realtime signal, so it would do wierd little speed ups to try and catch up and the picture would break up and it never got back in sync anyway and I had to stop and restart the channel. Other times though, it just freezes and completely locks up the RPi, requiring a hard reset.

Hi,

if i have read your earlier posts correctly you have tvheadend running on the same RPi.
What does your tvheadend service.log say? Are there Continuity errors or not?

Best Regards


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-11-17

(2013-11-17, 19:59)schub Wrote: Hi,

if i have read your earlier posts correctly you have tvheadend running on the same RPi.
What does your tvheadend service.log say? Are there Continuity errors or not?

Best Regards

Hey,

Yeah, I've got tvheadend and a USB tuner both on the RPi. The tuner is in an external hub which is powered by it's own PSU.

I didn't know about that log but I found it now and there are quite a lot of Continuity errors. I'll try and note when the problems happen in future so I can compare it to the log. http://xbmclogs.com/show.php?id=86287

Since disabling the overclock, I've had at least one instance where the TV froze for a short while but then resumed OK. No total lockups so far but I'll have to test for a bit longer.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - ted209 - 2013-11-18

(2013-11-17, 23:05)doveman2 Wrote: Yeah, I've got tvheadend and a USB tuner both on the RPi. The tuner is in an external hub which is powered by it's own PSU.

I have the same setup, running Openelec 3.2.3 (official). My setup freezes after between around 20 minutes and 2 hours. I have now removed my modest overclock setting and am testing further (had an hour's freeze free viewing yesterday).


Re: RE: OpenELEC Testbuilds for RaspberryPi Part 2 - wizzard72 - 2013-11-18

(2013-11-17, 11:22)wizzard72 Wrote:
(2013-11-14, 18:42)MilhouseVH Wrote:
(2013-11-14, 14:59)Koloss Wrote: Popcornmix or milhouse, can give us a new gotham build with newclock3 patch and airplay fix?

Here you go: Dropbox.

It's standard OpenELEC master plus newclock3 patches. I have no idea about any Airplay fix - unless it's been pushed upstream it's not in this build.

Thanks for the build. It's very fast. The only problem I have is that the subtitle downloader doesn't work. I think they are renewing it, but can't find the location to configure it. Anyone else having this issue?

Indeed they are renewing the subtitle downloaded: http://xbmc.org/making-subtitle-search-better/


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-11-18

@MilhouseVH, @miappa, @rbej,
There are some new PRs by Ben Avison looking at reducing the idle cpu load in xbmc (specifically on pi).
Together they should reduce CPU load by about 7.5% on a non-overclocked pi.
3674 (PR)
3676 (PR)
3677 (PR)

This is most obvious when on a static screen, but it should always have some benefit (e.g. when playing video).

I've pulled the commits into newlock3 and they work for me. I'd be interested if you can see any benefit, and if there are any regressions.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - pplucky - 2013-11-18

(2013-11-18, 18:59)wizzard72 Wrote: Indeed they are renewing the subtitle downloaded: http://xbmc.org/making-subtitle-search-better/
Although renewing may not mean improving, as it seems you'll have individual add-ons per subtitle search site (if someone develops it), rather than the existing unified interface (1 single add-on) in which you'd simply choose which sites to search subtitles on.
If you need to look for a subtitle in 3 different sites, this means you'd at least need to triple the time it takes to find a valid subtitle...

Was it my misunderstanding or does it really look like I described?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-11-18

(2013-11-18, 14:35)ted209 Wrote: I have the same setup, running Openelec 3.2.3 (official). My setup freezes after between around 20 minutes and 2 hours. I have now removed my modest overclock setting and am testing further (had an hour's freeze free viewing yesterday).

Ah, at least it's not just me then.

Mine does seem to be a lot better without the overclock, so maybe something about tvheadend or the tuner drivers is just very sensitive to overclocking. It will be a shame if we can't overclock because of this but maybe a less aggressive overclock than I had before might be OK.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Koloss - 2013-11-18

(2013-11-18, 19:03)popcornmix Wrote: @MilhouseVH, @miappa, @rbej,
There are some new PRs by Ben Avison looking at reducing the idle cpu load in xbmc (specifically on pi).
Together they should reduce CPU load by about 7.5% on a non-overclocked pi.
3674 (PR)
3676 (PR)
3677 (PR)

This is most obvious when on a static screen, but it should always have some benefit (e.g. when playing video).

I've pulled the commits into newlock3 and they work for me. I'd be interested if you can see any benefit, and if there are any regressions.

Good News!


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - craigbeat - 2013-11-18

This is good news indeed! I started looking at the source code yesterday, as I want to implement some speed ups on the EPG, especially when showing multiple days.

Looking at it quickly, it appears the way in which the EPG is generated is pretty inefficient (could be wrong about this). Also, I cannot work out how the cache works here, but again, not well used. My observations are that it's not the data fetching that's slow, but the way the Pi is trying to build the layout. On non-pi devices, there doesn't appear to be much of an issue.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-11-18

(2013-11-18, 19:03)popcornmix Wrote: @MilhouseVH, @miappa, @rbej,
There are some new PRs by Ben Avison looking at reducing the idle cpu load in xbmc (specifically on pi).
Together they should reduce CPU load by about 7.5% on a non-overclocked pi.
3674 (PR)
3676 (PR)
3677 (PR)

This is most obvious when on a static screen, but it should always have some benefit (e.g. when playing video).

I've pulled the commits into newlock3 and they work for me. I'd be interested if you can see any benefit, and if there are any regressions.

Definitely worth wider testing! With the above patches I'm seeing about 5% CPU load reduction in stock Confluence while idle on a 1GHz Pi (500Mhz core, 600Mhz SD-RAM) - idle CPU now hovers around 18% (23-24% previously).

Here's the new OE Gotham build on (Obsolete build - see later post for newer build).

Build details:
  • Tip of xbmc master (93077e6)
  • Tip of OpenELEC master (a1cd9cf)
  • Includes all newclock3 patches other than 3b5ad1e (cheaper GUI spinner)
  • Includes PR:3671 to ensure consistent webserver/GUI artwork caching
  • Excludes fernetmenta OpenELEC audio settings patch
You'll note from the list of newclock3 commits that there are two recent commits (55d3faa, 3af0df7) aimed at improving DVD subtitle synchronisation, so anyone having problems with subtitle synchronisation might want to give this build a go.

(2013-11-18, 22:43)craigbeat Wrote: This is good news indeed! I started looking at the source code yesterday, as I want to implement some speed ups on the EPG, especially when showing multiple days.

Looking at it quickly, it appears the way in which the EPG is generated is pretty inefficient (could be wrong about this). Also, I cannot work out how the cache works here, but again, not well used. My observations are that it's not the data fetching that's slow, but the way the Pi is trying to build the layout. On non-pi devices, there doesn't appear to be much of an issue.

I don't know if the EPG uses xml in any way, but there was some discussion on the OpenELEC issues list about using a more efficient XML parser library. Following one of the links in the discussion, it seems there are very significant performance differences between the different libraries (as much as 5 to 1), which makes me wonder if poor addon performance on Raspberry Pis is in many ways attributable to inefficient XML parsing.


This forum uses Lukasz Tkacz MyBB addons.