Kodi Community Forum

Full Version: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
(2015-05-17, 17:36)MONSTA Wrote: [ -> ]Thank you. Splash really slows system loading.

Looks nice though!
Maybe make it a little shorter? Smile Looks good, but 5 sec it's third part of whole loading time.
I'm having an issue with DLNA Audio running latest build
I havent updated in quite a long time so I will try to find the exact build when I first get the issue.
Might be wrong but can see a Curl error.
Basically the issue is as stated.
I'm trying to play audio from my android device via the Pi.
I'm using the app AirAudio (on my phone)
If I connect to the Airplay target then there is about 2 second delay before playback which is normal.
When connecting via UPNP/DLNA target then it takes about 20 seconds before playback begins. during this waiting time the Pi GUI is completely unresponsive

Log here
http://pastebin.com/jT5XXzXE
New OpenELEC Isengard build #0517: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.0.3 #1 Sun May 17 21:03:00 BST 2015 armv6l GNU/Linux

# vcgencmd version
May 13 2015 14:58:12
Copyright (c) 2012 Broadcom
version 8e0e0dbfe92be77d6355082451280d32f5bf0ff3 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150517210212-#0517-g6255426 [Build #0517]

# vcdbg log msg 2>&1 | grep DTOK
001536.550: Kernel trailer DTOK property says yes

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (6255426d, changelog) and tip of XBMC master (65e7de77, changelog) with the following modifications: Build Highlights:
  1. New kernel 4.0.3
  2. String/language cosmetics
Build Details:
  1. OpenELEC:
    • imx6: create images for diferent systems based on SYSTEM environment … (PR:4155, 1 commit, 3 files changed)
    • add imx6 mfgtool2 package (PR:4156, 1 commit, 1 file changed)
    • sqlite: dont build parallel (9bfe77e0)
    • scripts/create_addon: cosmetics (5d9b3625)
    • visualization.vsxu: temp dont build (6255426d)
  2. XBMC:
    • [PVR] Bump add-ons to fix debian packaging (PR:7147, 1 commit, 16 files changed)
    • dvdplayer: more ff/rw fixes (PR:7146, 1 commit, 3 files changed)
    • [strings][skin strings] take 3 - fix capitalization other string fixes (PR:7113, 2 commits, 2 files changed)
    • Allow uppercase input via SMS (PR:7074, 1 commit, 1 file changed)
    • upnp: fix renderer's PlayMedia() (PR:7011, 1 commit, 1 file changed)
    • [addons] show progress of repository updates (PR:6927, 5 commits, 9 files changed)
    • emergency fix: missing slash on close [/B] tag (PR:7151, 1 commit, 1 file changed)
    • emergency fix strings bracket on tag wrong way around (PR:7153, 1 commit, 1 file changed)
    • [strings] add files where string id is used (PR:7155, 1 commit, 1 file changed)
    • [TouchScreen] - Fixed touch screen support in WindowScreenCalibration (PR:7106, 2 commits, 2 files changed)
    • addons: fix fallback language handling for metadata (PR:7152, 1 commit, 1 file changed)
    • CLocalizeStrings: unify fallback language handling (fixes skin strings loading) (PR:7154, 1 commit, 3 files changed)
    • [lang] automatic cosmetics for the en_gb language file (950a8311)
    • [lang] update of skin.confluence language files (d84b1f7a)
  3. pvr.argustv:
    • Correct file permissions (PR:12, 1 commit, 1 file changed)
  4. pvr.demo:
    • Correct file permissions (PR:8, 1 commit, 1 file changed)
  5. pvr.dvblink:
    • Correct file permissions (PR:13, 1 commit, 1 file changed)
  6. pvr.dvbviewer:
    • Correct file permissions (PR:6, 1 commit, 1 file changed)
  7. pvr.filmon:
    • Correct file permissions (PR:10, 1 commit, 1 file changed)
  8. pvr.iptvsimple:
    • Correct file permissions (PR:16, 1 commit, 1 file changed)
  9. pvr.mediaportal.tvserver:
    • Correct file permissions (PR:7, 1 commit, 1 file changed)
  10. pvr.mythtv:
    • Correct file permissions (PR:9, 1 commit, 1 file changed)
  11. pvr.nextpvr:
    • Correct file permissions (PR:9, 1 commit, 1 file changed)
  12. pvr.njoy:
    • Correct file permissions (PR:6, 1 commit, 1 file changed)
  13. pvr.pctv:
    • Correct file permissions (PR:10, 1 commit, 1 file changed)
  14. pvr.stalker:
    • Correct file permissions (PR:6, 1 commit, 1 file changed)
  15. pvr.vbox:
    • Correct file permissions (PR:46, 1 commit, 1 file changed)
  16. pvr.vuplus:
    • Fileperm (PR:6, 2 commits, 2 files changed)
  17. pvr.wmc:
    • Correct file permissions (PR:7, 1 commit, 1 file changed)
  18. newclock4:
    • Commits no longer in build:
(2015-05-17, 11:15)Milhouse Wrote: [ -> ]
(2015-05-17, 09:15)miigotu Wrote: [ -> ]EDIT:
I have improved my nfs export definitions, which should eliminate any possible problems there. this is a much better/simpler approach than the guide on the wiki or the ubuntu wiki. Details here: https://gist.github.com/miigotu/c7df712997cd8745bd7a

crossmnt and nohide on the top /export are especially important, fsid=0 important for NFSv4.

You need to explain if you're using OS mounts in OpenELEC, or libnfs nfs:// mounts in Kodi (on OpenELEC).

libnfs doesn't support NFSv4, and will connect using NFSv3.

I'm not even sure if OpenELEC supports NFSv4 "natively", as an OS mount, and you may need to use mount.nfs4 installed from Unofficial (see: PR67), so you could be wasting your time (or simply causing yourself more grief) by trying to use NFSv4 exports - just stick with NFSv3, as this works no problem...

Edit: Reviewing your previous posts from April when you first reported the play-next issue, you were using nfs:// at the time, which is libnfs and doesn't support NFSv4... Mind you, it's the same libnfs in both Chimney and test builds, so wouldn't explain any performance difference.

Yes, I am limited to mounting the nfs shares with kodi since I use a shared mysql database and I don't want to have to configure each client's nfs shares in each client OS and they all have to be exactly the same in the DB. I wish I could use OS mounts as the performance presumably would be much better, just like the difference between the nfs server being in user space or kernel space.

My nfs definitions are both v3 and v4 compliant. The reason I wanted to go over the nfs exports was because with following the guides, if you mounted the top level (nfs://192.168.10.224: ) it showed all of the shares, but if you entered the export folder it was an empty folder, and if you directly went into export/Videos the files were there, but cd .. brought you back to an empty file list on the client. This confuses libnfs, and is noted in some of the exports documentation.

I did just update to the tonight's build (now that I have changed the exports) and it seems the extra delay is gone! So I assume it must be in how the exports were defined. I had originally followed instructions from https://help.ubuntu.com/community/SettingUpNFSHowTo and http://kodi.wiki/view/NFS#NFS_sharing_from_Linux and those instructions are both sub-optimal. They work, just not 100%, and not with the best performance.

I have noticed previously that when I scp a large file to the pi/pi2 like an update package, the speed starts out at around 2MB/s and continually drops down to about 200Kb/s, and a wget was pretty slow from it as well (pointing to some issue with wifi)

I will also do some tests with iperf and report tomorrow, I want to use the latest build for a bit and see if the problems resurface, as there have been times where it works well right after the update, but degrades over a day or two.

EDIT:
Auto play next issue, after 2-3 episodes it plays the next video with only a black screen (audio playing). This is playing with MMAL according to the log. Both MMAL and OMXPlayer were enabled.
http://sprunge.us/ETQP

And after disabling MMAL and only having OMXPlayer enabled, starting a video leaves the GUI up, no video, and plays audio. (no reboot in between)
http://sprunge.us/WRXh


If I leave MMAL enabled, and stop the video and start it again manually, it plays correctly.

EDIT2: When was libnfs updated from 1.9.6->1.9.7? There were some big changes to nested mounts in 1.9.7, which make exports need to be defined differently (the nfsv4 way). https://github.com/sahlberg/libnfs/issues/37 https://github.com/sahlberg/libnfs/commi...09cd8d00b0

According to http://forum.kodi.tv/showthread.php?tid=154279 NFS Clients mounting in the OS(kernel space) are 5-6 times faster than libnfs (userspace) -.-
Well my joy at seeing my USB tuner working with my RPi v2 was short-lived. I looked at the web interface sometime later and the adapters had completely disappeared and now of course selecting a programme from the EPG doesn't work, as there's no adapter available for it to tune into it with. I tried rebooting and that didn't help, so I'll try disconnecting the power and see if that gets it working again but obviously this is too unstable to be used properly at the moment, so I'll focus on getting it working with the RPi B as my brother has one of those he can use as a backend, with the v2 just used as a frontend.
(2015-05-18, 08:12)miigotu Wrote: [ -> ]EDIT:
Auto play next issue, after 2-3 episodes it plays the next video with only a black screen (audio playing). This is playing with MMAL according to the log. Both MMAL and OMXPlayer were enabled.
http://sprunge.us/ETQP

And after disabling MMAL and only having OMXPlayer enabled, starting a video leaves the GUI up, no video, and plays audio. (no reboot in between)
http://sprunge.us/WRXh

This still smells of a network problem, although @popcornmix will need to confirm.

I really wish you could test, even briefly, with a wired connection, as WiFi is probably the most unreliable way of connecting. Or invest in Homeplugs, as when they work they're great (although like WiFi, they can also be at the mercy of the environment).

I'm not saying there isn't a problem elsewhere in OpenELEC or these test builds, but while WiFi is involved in the mix it's just too likely to be the cause - who knows, maybe a neighbour has treated themselves to a new more powerful wireless router on the same channel as you, and is now clobbering your signal from time to time. Or their old microwave has developed a leak. Testing with a wire eliminates WiFi as a variable and allows everyone to focus on what's left, assuming the problem remains.

(2015-05-18, 08:12)miigotu Wrote: [ -> ]EDIT2: When was libnfs updated from 1.9.6->1.9.7? There were some big changes to nested mounts in 1.9.7, which make exports need to be defined differently (the nfsv4 way). https://github.com/sahlberg/libnfs/issues/37 https://github.com/sahlberg/libnfs/commi...09cd8d00b0

OpenELEC master updated from libnfs 1.9.5 to 1.9.7 on 2 May 2015 (1.9.6 was skipped entirely).

These test builds have included the nested mount change since being committed to libnfs master on 17 Jan 2015, so hardly a recent change if you've been using my builds since that time.

Both Chimney builds and these test builds are now using essentially the same version of libnfs (the test build has a handful of extra, mostly cosmetic, commits). Honestly, if there was a serious problem with libnfs 1.9.7 I think we'd have heard more about it by now.

(2015-05-18, 08:12)miigotu Wrote: [ -> ]According to http://forum.kodi.tv/showthread.php?tid=154279 NFS Clients mounting in the OS(kernel space) are 5-6 times faster than libnfs (userspace) -.-
OS mounts are well known to perform better than libnfs (although not really 5-6 times better, at least not when wired...) and attempts have been made at improving libnfs performance but more investigation is required.
(2015-05-18, 16:42)Milhouse Wrote: [ -> ]OS mounts are well known to perform better than libnfs (although not really 5-6 times better, at least not when wired...) and attempts have been made at improving libnfs performance but more investigation is required.

I think the main reason I decided to stick with Kodi mounts is that with OS mounts, the boot hangs at startup if the PC isn't on and the share isn't available. Perhaps it would work to use a WOL command and a suitable delay before attempting the OS mount to avoid this problem but I don't know if that's possible with OE at present.
My USB tuner on the RPi v2 is still not working after disconnecting the power and unplugging the tuner and reconnecting it. I wonder if it's just not supplying sufficient power to the USB ports? I recall there was some way of increasing this, is that worth trying?

EDIT: With my RPi B, the adapter shows in the web interface and it loads the EPG on boot but then I just get a black screen trying to go the EPG, the debug overlay freezes and it reboots. This is with #515. In fact, after rebooting I tried again and the EPG did open after a while this time and I was able to start a channel but the video looked about 1fps, whilst the audio seemed normal.

The log's too big to pastebin, so I've uploaded it here: https://drive.google.com/file/d/0B1fDI89...sp=sharing

It's a bit confusing to me as the timestamps start an hour behind each time and then jump forward to the correct time after "INFO: creating subdirectories" but the 15:28/16:28 part should be when it rebooted and the 15:30/16:30 part when I managed to start a channel. For some reason, it seems to have repeated the 15:28/16:28 log about 3/4 of the way down as well and a log from 19:30 (not sure which date) at the end. I've left it all in as I don't know what's important but if there's stuff I can leave out let me know, as then I might be able to fit it on pastebin in future.

I'm going to try with #517 now.

EDIT2: Bugger it, it seems I didn't edit the config.txt after I had to re-image my SD, so it's not overclocked and more importantly doesn't have my MPEG2 decode key so the TV will be playing unaccelerated Sorry for the noise!
(2015-05-18, 17:21)doveman2 Wrote: [ -> ]I think the main reason I decided to stick with Kodi mounts is that with OS mounts, the boot hangs at startup if the PC isn't on and the share isn't available. Perhaps it would work to use a WOL command and a suitable delay before attempting the OS mount to avoid this problem but I don't know if that's possible with OE at present.

Settings -> System -> Power saving -> Try to wakeup remote servers on access
(2015-05-18, 17:26)doveman2 Wrote: [ -> ]My USB tuner on the RPi v2 is still not working after disconnecting the power and unplugging the tuner and reconnecting it. I wonder if it's just not supplying sufficient power to the USB ports? I recall there was some way of increasing this, is that worth trying?

Does your tuner require more than 600mA (but less than 1200mA) and your power supply is capable of supplying that current?
If so, then add "max_usb_current=1" to config.txt.
(2015-05-18, 17:28)Milhouse Wrote: [ -> ]
(2015-05-18, 17:21)doveman2 Wrote: [ -> ]I think the main reason I decided to stick with Kodi mounts is that with OS mounts, the boot hangs at startup if the PC isn't on and the share isn't available. Perhaps it would work to use a WOL command and a suitable delay before attempting the OS mount to avoid this problem but I don't know if that's possible with OE at present.

Settings -> System -> Power saving -> Try to wakeup remote servers on access

Does that have any effect when the OS is trying to mount a share at boot though, before Kodi is loaded?
(2015-05-18, 18:01)popcornmix Wrote: [ -> ]Does your tuner require more than 600mA (but less than 1200mA) and your power supply is capable of supplying that current?
If so, then add "max_usb_current=1" to config.txt.

The PSU is 2A so no problem there. I'm not sure how much power the tuner requires but it works fine on my B, so unless the v2 defaults to supplying less power to the USB ports than the B I guess it's probably not power related. Guess it won't hurt to try adding that line and see if it makes a difference though.
(2015-05-18, 18:40)doveman2 Wrote: [ -> ]The PSU is 2A so no problem there. I'm not sure how much power the tuner requires but it works fine on my B, so unless the v2 defaults to supplying less power to the USB ports than the B I guess it's probably not power related. Guess it won't hurt to try adding that line and see if it makes a difference though.

Adding "max_usb_current=1" is pretty harmless. Worst case is the USB port will swallow more current than the PSU supplies, and the voltage drop will crash the Pi, but from what you've said that seems unlikely to occur. Give it a try and see if it helps.
(2015-05-17, 19:29)MONSTA Wrote: [ -> ]Maybe make it a little shorter? Smile Looks good, but 5 sec it's third part of whole loading time.

You can replace with a h.264 file of your own choosing. There were some alternatives here,
and we posted instructions for converting to the format required on this testbuild thread (probably in part 1).

When we added the video, it was about right for boot time on a Pi1. Pi2 boots faster, and faster sdcards are more common now.

Note: The video doesn't slow down boot - it runs in parallel and makes barely any difference to boot time, as long as both are of similar duration.
But Kodi does wait until splash video has completed before taking over the screen, otherwise the abrupt stopping of video looks a bit ugly.