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 - bobby8921 - 2014-03-25

Hi,
I am looking for buying a RPi, but I have some questions.
With this build, Airplay has been fixed with iOS 7.1, isn't it ?
Is it possible to watch soccer streaming ?

Thanks for your answers


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - FAMMAR - 2014-03-25

(2014-03-25, 23:01)bobby8921 Wrote: Hi,
I am looking for buying a RPi, but I have some questions.
With this build, Airplay has been fixed with iOS 7.1, isn't it ?
Is it possible to watch soccer streaming ?

Thanks for your answers

Hello Bobby

This thread is about Gotham testbuilds, so this is for testing builds. If you want to buy a Pi I would start using the stable version 12.2 first, and yes you can see soccer streaming but this is not the thread to discuss this


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - bobby8921 - 2014-03-25

oh ok, I thought we had to run this builds to have Airplay support, that's why I came here.


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

(2014-03-25, 23:07)bobby8921 Wrote: oh ok, I thought we had to run this builds to have Airplay support, that's why I came here.

If you read this thread (or at least the last couple of weeks of it) there are a number of reports of airplay working well in recent builds.
(It works well for me).


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - bobby8921 - 2014-03-25

Good to know.
Last question, if Milhouse does an update of his build, will it auto-update when I will turn on my RPi ?

Thank you for your help


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

(2014-03-25, 23:34)bobby8921 Wrote: Last question, if Milhouse does an update of his build, will it auto-update when I will turn on my RPi ?

No. Updating is pretty easy. The Pi exposes a shared smb directory called update. You just download the tar file into that shared directory and reboot.
I think there is also an openelec add-on which can directly install these builds.


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

(2014-03-25, 23:38)popcornmix Wrote: No. Updating is pretty easy. The Pi exposes a shared smb directory called update. You just download the tar file into that shared directory and reboot.
I think there is also an openelec add-on which can directly install these builds.

Does this also work if booting from USB?


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

(2014-03-26, 00:43)pplucky Wrote: Does this also work if booting from USB?

Yep this also works.
But you don't boot from usb, you just have your data stored on usb. The boot partition is on your sd card.


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

If you have boot=/dev/mmcblk0p1 (ie. the SD card) then you can use the "easy" update solution of dropping the new tar into the update folder and rebooting. However if you are "booting" from some other device (nfs, smb, usb) then you can't use this method and must update your installation yourself by picking apart the files from with the tar and copying to the correct location. There really is no benefit to not booting from the SD card, just plenty of downside.


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

New OpenELEC Gotham build: #0326
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.13.7 #1 PREEMPT Wed Mar 26 02:50:23 GMT 2014 armv6l GNU/Linux

# vcgencmd version
Mar 25 2014 15:17:24
Copyright (c) 2012 Broadcom
version 34a027868674ccc896149263215e91718770698f (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20140326031537-r18011-gae1cb22

Based on tip of XBMC master (00ea74f, changelog) and tip of OpenELEC master (ae1cb22, changelog) with the following modifications:
  • Includes newclock3 commits (except for 7b5ce9c which I've replaced with a static spinner to avoid hammering the GUI)
  • Excludes the OpenELEC fernetmenta patches (due to conflict with newclock3)
  • 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.
  • Default setting for "Show RSS Feed" changed to disabled
  • Disabled "Total Duration" in Confluence (see build #0221 for details)
  • ALSA is enabled and any suitable hardware should be available in XBMC Audio Settings
  • Includes newclock3: "More efficient infobool expression evaluator" (reverted in stock OpenELEC)
  • Includes newclock3: "Allow small audio packets to be concatenated to make better use of audio fifo" (reverted in stock OpenELEC)
Build Highlights:

New firmware, new 3.13.7 kernel, and two new features added to newclock3.
  1. New Firmware Mar 25:
    • kernel: fix sign in sdhci_bcm2708_raw_writel wait calculation. see: raspberrypi/linux#549
    • firmware: audio_mixer: Support 8-bit input and float input and output. Support non-power of 2 channels
    • firmware: When hotplug is absent, try reading the edid as a fallback. Only switch to composite if both fail
  2. OpenELEC:
    • New kernel: 3.13.7
    • wlan-firmware: update to wlan-firmware-0.0.18
    • systemd: update to systemd-212
  3. XBMC:
    • Fixed import of fanart for an exported library
    • PVR and subtitle fixes
  4. newclock3:
    • Commit that makes large wtv files open in a couple of seconds rather than 60
    • GPU acceleration of format conversion, audio mixing and resampling in dvdplayer and paplayer - from popcornmix:
      Quote:I've been tinkering with this for some weeks (it's required quite a bit of extending what audio_mixer supports in gpu firmware).

      But it's now ready for testing.

      It potentially significantly reduces arm cpu when using ActiveAE (either PiSink or ALSA) - i.e. using paplayer or dvdplayer. No change in omxplayer.
      It accelerates audio format conversion, up/down mixing and resampling.

      How much it helps depends on various things:
      The number of input and output channels (bigger improvement when these are different)
      Whether resampling is required (e.g. with "fixed" output configuration, or optimised when playing multiple files with different sampling rates)
      Every time sink is opened, the gui sounds get resampled, so this should help here.
      The format of the audio (we now support 8, 16 and 32-bit integer and floating point directly on GPU) so can avoid some arm side format converts.

      It should be most obvious when playing multichannel audio (either with paplayer or dvdplayer) and downmixing to stereo (i.e. without passthrough).

      It's a fairly big change, so plenty of potential for breakage. It's working fine in my test cases.

      Requires updated firmware.
      Quote:I'm not seeing a big change with downmixing when playing a video. Resampling does show a big win:

      Before:
      Code:
      17:16:51 5703.514160 T:3056354400  NOTICE: ActiveAE::ResampleSounds - resample /opt/xbmc-bcm/xbmc-dbg/arm-linux-gnueabihf/arm-linux-gnueabihf/share/xbmc/addons/skin.confluence/sounds/cursor.wav took 232ms
      17:16:52 5703.780273 T:3056354400  NOTICE: ActiveAE::ResampleSounds - resample /opt/xbmc-bcm/xbmc-dbg/arm-linux-gnueabihf/arm-linux-gnueabihf/share/xbmc/addons/skin.confluence/sounds/click.wav took 266ms
      17:16:52 5704.019043 T:3056354400  NOTICE: ActiveAE::ResampleSounds - resample /opt/xbmc-bcm/xbmc-dbg/arm-linux-gnueabihf/arm-linux-gnueabihf/share/xbmc/addons/skin.confluence/sounds/back.wav took 239ms
      17:16:52 5704.306641 T:3056354400  NOTICE: ActiveAE::ResampleSounds - resample /opt/xbmc-bcm/xbmc-dbg/arm-linux-gnueabihf/arm-linux-gnueabihf/share/xbmc/addons/skin.confluence/sounds/shutter.wav took 287ms
      17:16:53 5704.928223 T:3056354400  NOTICE: ActiveAE::ResampleSounds - resample /opt/xbmc-bcm/xbmc-dbg/arm-linux-gnueabihf/arm-linux-gnueabihf/share/xbmc/addons/skin.confluence/sounds/notify.wav took 621ms
      17:16:53 5704.950684 T:3056354400  NOTICE: ActiveAE::ResampleSounds - resample /opt/xbmc-bcm/xbmc-dbg/arm-linux-gnueabihf/arm-linux-gnueabihf/share/xbmc/addons/skin.confluence/sounds/out.wav took 22ms

      After:
      Code:
      17:14:11 5543.333984 T:3056796768  NOTICE: ActiveAE::ResampleSounds 0 - resample /opt/xbmc-bcm/xbmc-dbg/arm-linux-gnueabihf/arm-linux-gnueabihf/share/xbmc/addons/skin.confluence/sounds/cursor.wav took 111ms
      17:14:11 5543.444336 T:3056796768  NOTICE: ActiveAE::ResampleSounds 0 - resample /opt/xbmc-bcm/xbmc-dbg/arm-linux-gnueabihf/arm-linux-gnueabihf/share/xbmc/addons/skin.confluence/sounds/click.wav took 110ms
      17:14:11 5543.554199 T:3056796768  NOTICE: ActiveAE::ResampleSounds 0 - resample /opt/xbmc-bcm/xbmc-dbg/arm-linux-gnueabihf/arm-linux-gnueabihf/share/xbmc/addons/skin.confluence/sounds/back.wav took 110ms
      17:14:12 5543.664062 T:3056796768  NOTICE: ActiveAE::ResampleSounds 0 - resample /opt/xbmc-bcm/xbmc-dbg/arm-linux-gnueabihf/arm-linux-gnueabihf/share/xbmc/addons/skin.confluence/sounds/shutter.wav took 110ms
      17:14:12 5543.784180 T:3056796768  NOTICE: ActiveAE::ResampleSounds 0 - resample /opt/xbmc-bcm/xbmc-dbg/arm-linux-gnueabihf/arm-linux-gnueabihf/share/xbmc/addons/skin.confluence/sounds/notify.wav took 120ms
      17:14:12 5543.884766 T:3056796768  NOTICE: ActiveAE::ResampleSounds 0 - resample /opt/xbmc-bcm/xbmc-dbg/arm-linux-gnueabihf/arm-linux-gnueabihf/share/xbmc/addons/skin.confluence/sounds/out.wav took 100ms

      and much of the GPU accelerated time is "non-busy" so the arm can do other things). It should mean the key presses are silent for less time after opening the sink.

Additional Testing Notes:
  1. Testers should try adding the following entry to their advancedsettings.xml:
    Code:
    <advancedsettings>
      <video>
        <defaultplayer>dvdplayer</defaultplayer>
        <defaultdvdplayer>dvdplayer</defaultdvdplayer>
      </video>
    </advancedsettings>
    and report if it is better/worse than omxplayer. You can still play files with omxplayer using the context-menu "Play using... OMXPlayer".

  2. The following settings are no longer required in config.txt and should be removed:
    Code:
    no_hdmi_resample=1
    hdmi_stream_channels=1
    no_resample_audio is now a default, and hdmi_stream_channels is switched based on audio content. For the time being when using passthrough, 2.0 speaker layout should continue to be used (you will still get 5.1 with AC3/DTS).

  3. The FIQ_FSM patch is now enabled by default in OpenELEC master. See the FIQ_FSM announce thread for details.

    One new feature, currently disabled by default, is accelerated support of high-speed isochronous transactions (webcams, real time devices, etc.). There's a possibility this could be used by ALSA or DVB modules (although not always) which may affect some users (hopefully for the better). If you might benefit from this, enable by adding the following option to the end of the line in your /flash/cmdline.txt file:
    Code:
    dwc_otg.fiq_fsm_mask=0x7



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

(2014-03-25, 20:59)bagofcrap24 Wrote:
(2014-03-25, 18:12)evangelion Wrote: Just curious about something.

A clean install then update to the latest Millhouse build results in the rainbow splash, OpenElec screen, followed by a nice Gotham Freeze XBMC logo on boot.

An already existing install, followed by an update to the same Millhouse build, results in the rainbow splash, OpenElec, and then a generic XBMC logo?

Why is that? And out of interest where is the XBMC boot logo stored?

You had likely had a custom splash on at some point.

if you place a splash.png in /storage/.xbmc/media/ it will override the default xbmc boot splash.
as its in /storage it survives upgrades

There's nothing in /storage/.xbmc/media/ though, it's an empty folder?

So why doesn't an update display the Gotham Freeze logo on boot, instead of a generic one, as a fresh install does? And where IS the default logo stored?


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

(2014-03-26, 12:19)evangelion Wrote:
(2014-03-25, 20:59)bagofcrap24 Wrote:
(2014-03-25, 18:12)evangelion Wrote: Just curious about something.

A clean install then update to the latest Millhouse build results in the rainbow splash, OpenElec screen, followed by a nice Gotham Freeze XBMC logo on boot.

An already existing install, followed by an update to the same Millhouse build, results in the rainbow splash, OpenElec, and then a generic XBMC logo?

Why is that? And out of interest where is the XBMC boot logo stored?

You had likely had a custom splash on at some point.

if you place a splash.png in /storage/.xbmc/media/ it will override the default xbmc boot splash.
as its in /storage it survives upgrades

There's nothing in /storage/.xbmc/media/ though, it's an empty folder?

So why doesn't an update display the Gotham Freeze logo on boot, instead of a generic one, as a fresh install does? And where IS the default logo stored?

XBMC built from the master branch uses the old Splash png: https://github.com/xbmc/xbmc/blob/master/media/Splash.png

XBMC built from the Gotham branch uses the new "freeze" Splash.png: https://github.com/xbmc/xbmc/blob/Gotham/media/Splash.png

So you would have seen the new "freeze" splash when clean installing OE Beta1 or Beta2, but then having updated to my build you'd see the old non-freeze splash as you've now switched from the Gotham-branch build to a master-branch build.


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

(2014-03-26, 12:19)evangelion Wrote: There's nothing in /storage/.xbmc/media/ though, it's an empty folder?

So why doesn't an update display the Gotham Freeze logo on boot, instead of a generic one, as a fresh install does? And where IS the default logo stored?

My best guess that it hasnt updated properly then.
The logo is stored within the SYSTEM file which means if its updated then it has to include it.
it gets mapped to the file SYSTEM : /usr/share/xbmc/media/splash.png

Actually I still don't understand how you can have the freeze logo. I have it on mine because i put it in /storage/.xbmc/media/
Todays build doesnt include the Freeze Logo and neither did the last 2 builds before that


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

It's there alright, I just booted it and lo and behold the Freeze logo appears. It's also in the path you described.

Edit: Ahh I think I see what Millhouse was getting at now, it didn't peg at first but now it's sinking in. Both Pi's are running Git 745067f - 23 Mar 14 (17998) The CLEAN install though is XBMC 13.0-Beta3, the UPDATED install is XBMC 14.0-Alpha.


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

(2014-03-26, 01:02)MilhouseVH Wrote: There really is no benefit to not booting from the SD card, just plenty of downside.
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?


This forum uses Lukasz Tkacz MyBB addons.