Kodi Community Forum
v18 LibreELEC Testbuilds for x86_64 (Kodi 18.0) - 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: Linux (https://forum.kodi.tv/forumdisplay.php?fid=52)
---- Thread: v18 LibreELEC Testbuilds for x86_64 (Kodi 18.0) (/showthread.php?tid=298462)



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - wheemer - 2017-12-27

(2017-12-27, 00:04)WaVe_99 Wrote:
(2017-12-18, 23:00)wheemer Wrote: They are appearing just at boot but right before the splash screen... I will try your fix and report back, thanks!


wheemer - same at my NUC Kaby Lake last bios 060 and last build... But after boot everything works fine... Some ACPI error AE_NOT_FOUND... 
 Yeah setting the loglevel to 0 helped to clean up those erroneous errors and make the install look better.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - loktar - 2017-12-27

The libretro addon is disabled on #1226


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - solidsatras - 2017-12-27

Hello Milhouse,

I think I found a bug.
Playing content(x264,x265) results in a black screen and no audio but the time keeps going.

Traced it back to be between these versions:   (also tested with #1217; #1219; #1226)

Just for reference, log for the latest version:
  • Log #1226 - Screenshot - For some reason the screen isn´t black anymore. But it is a still image and no audio.

Setup:
NUC6CAYH (J3455 - Apollo Lake)

I noticed that the 'Audio stream' isn´t recognized. Maybe that has something to do with it.
In my setup I use SPDIF output of the NUC connected to a Denon AVR-3803. That may be strange in this day and age Wink
If I can do anything else to track this down, I´m happy to do more tests.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2017-12-27

(2017-12-27, 16:56)solidsatras Wrote: I think I found a bug.
Playing content(x264,x265) results in a black screen and no audio but the time keeps going.

For some reason Kodi is unable to initialise your audio device:
Code:
14:01:03.626 T:139634863343360   DEBUG: CActiveAESink::OpenSink - trying to open device ALSA:Default
14:01:03.626 T:139634863343360    INFO: CAESinkALSA::Initialize - Attempting to open device "Default"
14:01:03.627 T:139634863343360    INFO: CAESinkALSA - Unable to open device "Default:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x02" for playback
14:01:03.627 T:139634863343360    INFO: CAESinkALSA - Unable to open device "Default" for playback
14:01:03.627 T:139634863343360   ERROR: CAESinkALSA::Initialize - failed to initialize device "Default"
14:01:03.627 T:139634863343360   DEBUG: CActiveAESink::OpenSink - trying to open device ALSA:@
14:01:03.627 T:139634863343360    INFO: CAESinkALSA::Initialize - Attempting to open device "@"
14:01:03.632 T:139634863343360    INFO: CAESinkALSA - Unable to open device "sysdefault:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x02" for playback
14:01:03.662 T:139634863343360    INFO: CAESinkALSA::Initialize - Opened device "sysdefault"
14:01:03.663 T:139634863343360    INFO: CAESinkALSA::InitializeHW - Your hardware does not support AE_FMT_S16NE, trying other formats
14:01:03.663 T:139634863343360   ERROR: CAESinkALSA::InitializeHW - Unable to find a suitable output format
14:01:03.663 T:139634863343360   ERROR: CActiveAESink::OpenSink - no sink was returned
14:01:03.663 T:139634871736064   ERROR: ActiveAE::InitSink - returned error
Can you double-check your audio devices are configured correctly after #1216 - your settings might have become a little jumbled as devices appeared/disappeared.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - orrpan - 2017-12-27

(2017-12-27, 17:34)Milhouse Wrote:
(2017-12-27, 16:56)solidsatras Wrote: I think I found a bug.
Playing content(x264,x265) results in a black screen and no audio but the time keeps going.

For some reason Kodi is unable to initialise your audio device:
Code:
14:01:03.626 T:139634863343360 DEBUG: CActiveAESink::OpenSink - trying to open device ALSA:Default
14:01:03.626 T:139634863343360 INFO: CAESinkALSA::Initialize - Attempting to open device "Default"
14:01:03.627 T:139634863343360 INFO: CAESinkALSA - Unable to open device "Default:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x02" for playback
14:01:03.627 T:139634863343360 INFO: CAESinkALSA - Unable to open device "Default" for playback
14:01:03.627 T:139634863343360 ERROR: CAESinkALSA::Initialize - failed to initialize device "Default"
14:01:03.627 T:139634863343360 DEBUG: CActiveAESink::OpenSink - trying to open device ALSA:@
14:01:03.627 T:139634863343360 INFO: CAESinkALSA::Initialize - Attempting to open device "@"
14:01:03.632 T:139634863343360 INFO: CAESinkALSA - Unable to open device "sysdefault:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x02" for playback
14:01:03.662 T:139634863343360 INFO: CAESinkALSA::Initialize - Opened device "sysdefault"
14:01:03.663 T:139634863343360 INFO: CAESinkALSA::InitializeHW - Your hardware does not support AE_FMT_S16NE, trying other formats
14:01:03.663 T:139634863343360 ERROR: CAESinkALSA::InitializeHW - Unable to find a suitable output format
14:01:03.663 T:139634863343360 ERROR: CActiveAESink::OpenSink - no sink was returned
14:01:03.663 T:139634871736064 ERROR: ActiveAE::InitSink - returned error
Can you double-check your audio devices are configured correctly after #1216 - your settings might have become a little jumbled as devices appeared/disappeared.  
 Had the similar problem, no audio over HDMI:

Code:
LibreELEC:~/.config # dmesg | grep error
[    8.617896] snd_hda_codec_hdmi: probe of hdaudioC0D3 failed with error -16

modprobe the failed in ./config/autostart.sh

Code:
modprobe hdaudioC0D3

then a reboot, and it was up and running again


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2017-12-28

New LibreELEC.tv Leia build #1227: Generic
(Supercedes previous build)

SHA256 Checksum: 66c7353a315949139189743a0a84d3876eb315510b618c06a0636514f67bffbd (Generic)

Code:
# uname -a
Linux NUC 4.14.7 #1 SMP Thu Dec 28 02:07:01 GMT 2017 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20171228015357-#1227-gbf7eef4 [Build #1227]

# Kodi version
(18.0-ALPHA1 Git:7b1ff23). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (bf7eef4, changelog) and tip of XBMC master (d799240, changelog) with the following modifications: Build Highlights:
  1. Drop log upload authentication, still using ix.io
  2. samba: update to samba-4.7.4
  3. bluez: update to 5.48
Build Details:
  1. LibreELEC.tv:
    • nss/nspr: build full host library (PR:2349, 2 commits, 6 files changed)
    • configs: enable VM_EVENT_COUNTERS for project consistency (PR:2358, 1 commit, 7 files changed)
  2. XBMC:
    • FIX: [droid] fix oreo video view shrinkage (PR:13241, 2 commits, 3 files changed)
    • changed: group set related info in a struct (PR:13225, 1 commit, 7 files changed)
    • add dateadded sort method to tvshows library node (PR:13247, 1 commit, 1 file changed)
    • [PVR][Estuary] PVRInfoPanel cleanup. (PR:13255, 2 commits, 7 files changed)
  3. Additional commits/pull requests/changes not yet merged upstream:



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - nicram - 2017-12-28

(2017-12-27, 00:05)Milhouse Wrote:
(2017-12-26, 23:11)nicram Wrote: I'm playing with LibreELEC a lot those days.
But I still got 1 thing that do not work for me like i would like Smile I configure auto sleep when it's idle for 15 minutes. But when i do action thru ssh, or when i copy files by SMB from outside, then it still go to sleep, like it wouldn't detect that things are happening.

Because it doesn't detect that things are happening. Kodi is putting the device to sleep when **Kodi is idle**, in your case after 15 minutes.

Kodi knows nothing about your SSH or Samba activity. If you intend to use the device for things other than Kodi (ie. ssh, Samba) then you render your device incompatible with Kodi power management and will need to roll your own method of suspending your device.  
Well, i'm treating LibreELEC with KODI, as whole. So for me, it's not KODI that go to sleep, but whole device (OS and it's software). From this perspective it's strange, that SMB that is turn on by default making device accessible from outside, don't care when i use it. It's built to work with it.
But maybe i can fix it by myself. Does KODI/LibreELEC run script before sleep? So i could make it check with it, and if there is something going on - interrupt going to sleep.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2017-12-29

New LibreELEC.tv Leia build #1228: Generic
(Supercedes previous build)

SHA256 Checksum: 653a9e35ed2fe57784585372c9addb52f6baa8a16205e91221c0298cc27ccb64 (Generic)

# uname -a
Linux NUC 4.14.7 #1 SMP Thu Dec 28 21:47:55 GMT 2017 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20171228214630-#1228-g1fbc48c [Build #1228]

# Kodi version
(18.0-ALPHA1 Git:7b1ff23). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (1fbc48c, changelog) and tip of XBMC master (ffc89f6, changelog) with the following modifications: Build Highlights:
  1. Inputstream, PVR API 5.8.0 changes
Build Details:
  1. LibreELEC.tv:
    • systemd: update to 236 (PR:2331, 1 commit, 1 file changed)
    • passthrough: drop kernel patch, force full (PR:2329, 1 commit, 2 files changed)
    • samba: update to samba-4.7.4 (PR:2360, 2 commits, 3 files changed)
    • zstd: update to zstd-1.3.3 (PR:2345, 1 commit, 1 file changed)
  2. XBMC:
    • [fix][cmake] allow building without lirc after ddc50b2 (PR:13256, 1 commit, 1 file changed)
    • [Win10] Implementation UWP own power management and storage provider (PR:13254, 6 commits, 28 files changed)
    • ITime and INPUTSTREAM_INFO::m_name implementation for inputstream (PR:13226, 4 commits, 6 files changed)
    • [PVR][guiinfo][skin] PVR Addon API 5.8.0: Remove unused/deprecated API functions (PR:13228, 4 commits, 17 files changed)
  3. inputstream.adaptive:
  4. inputstream.rtmp:
    • Fix CMakeLists project name (mpd -> rtmp) (482f5c1)
  5. pvr.argustv:
    • PVR API 5.8.0 (PR:78, 1 commit, 3 files changed)
  6. pvr.demo:
    • PVR API 5.8.0 (PR:57, 1 commit, 3 files changed)
  7. pvr.filmon:
    • PVR API 5.8.0 (PR:81, 1 commit, 3 files changed)
    • update jsoncpp methods to non deprecated versions (PR:80, 1 commit, 3 files changed)
  8. pvr.hdhomerun:
    • PVR API 5.8.0 changes (PR:73, 2 commits, 4 files changed)
    • typo: add missing l (PR:74, 1 commit, 1 file changed)
  9. pvr.hts:
    • Implement API function GetStreamTimes & PVR Addon API 5.8.0 (PR:346, 1 commit, 9 files changed)
  10. pvr.iptvsimple:
    • PVR API 5.8.0 (PR:172, 1 commit, 3 files changed)
  11. pvr.mediaportal.tvserver:
    • PVR API 5.8.0 (PR:80, 1 commit, 4 files changed)
  12. pvr.mythtv:
    • PVR API 5.8.0 (PR:92, 1 commit, 4 files changed)
  13. pvr.njoy:
    • PVR API 5.8.0 (PR:45, 1 commit, 3 files changed)
  14. pvr.pctv:
    • PVR API 5.8.0 (PR:57, 1 commit, 3 files changed)
    • Fix deprecated function warnings (PR:55, 3 commits, 5 files changed)
  15. pvr.stalker:
    • PVR API 5.8.0 (PR:105, 1 commit, 3 files changed)
    • jsoncpp deprecated function change (PR:103, 1 commit, 3 files changed)
  16. pvr.teleboy:
    • Remove api functions (33c3b02)
    • Update changelog and version (3ae0297)
  17. pvr.vbox:
    • PVR API 5.8.0 (PR:206, 1 commit, 3 files changed)
  18. pvr.vdr.vnsi:
    • PVR API 5.8.0 (PR:12, 1 commit, 4 files changed)
  19. pvr.vuplus:
    • PVR API 5.8.0 (PR:81, 1 commit, 3 files changed)
  20. pvr.zattoo:
  21. Additional commits/pull requests/changes not yet merged upstream:
    • Added: [env] PR:2323 (perma): buildsystem: source functions earlier, validate project/arch earlier, refactor show_config



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2017-12-30

New LibreELEC.tv Leia build #1229: Generic
(Supercedes previous build)

SHA256 Checksum: ac8507a32daf7bdd4be7c683875d1aa01227b366150b36a697fb3a909c633025 (Generic)

# uname -a
Linux NUC 4.14.9 #1 SMP Fri Dec 29 23:20:54 GMT 2017 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20171229231928-#1229-g211f8b5 [Build #1229]

# Kodi version
(18.0-ALPHA1 Git:7b1ff23). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (211f8b5, changelog) and tip of XBMC master (f3271af, changelog) with the following modifications: Build Highlights:
  1. New 4.14.9 kernel
  2. OpenGL: boost shader performance for Lanczos3 optimized
  3. [PVR] Fix crash when enabling a PVR client addon
Build Details:
  1. LibreELEC.tv:
    • systemd: enable hostnamed and add patch to fix systemd-analyze plot (PR:2364, 2 commits, 2 files changed)
    • systemd: make sleep.conf.d configurable by user (PR:2346, 1 commit, 3 files changed)
  2. XBMC:
    • Stacks - some refactoring and bug fixes (PR:13235, 11 commits, 8 files changed)
    • [PVR] Fix parental locked channels snafu. (PR:13261, 1 commit, 1 file changed)
    • OpenGL: boost shader performance for Lanczos3 optimized (PR:13260, 10 commits, 36 files changed)
    • [docs] android uses clang 5.0 since d32bd6656f (81d49bd)
  3. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: [env] PR:2317 (perma): linux: update to linux-4.14.9
    • Added: [pkg] PR:13266 (perma): [PVR] Fix crash when enabling a PVR client addon.



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2017-12-30

Weekly Linux 4.15-rc5 build #1229x: Generic

Packages disabled/not included:
Code:
RTL8192EU
RTL8812AU
bcm_sta
DVB Driver Addons
Packages added/updated:
Code:
RTL8188EU
RTL8192DU
Known issues:
Code:
Switch to in-kernel RTL8192CU



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - HeresJohnny - 2017-12-30

Hello Milhouse,

first of all, thanks for your continuing service to the community and your persistance!

I've been lurking in this thread and installing builds for several months now. I would like to tackle an issue that has never worked so far, unfortunately: NFS networking. My setup is a MySQL database and several windows and libreelec clients in the house. Until recently I used SMB to connect to sources but yesterday I tried switching to NFS (again). Now I remember why I abandoned this approach in the first place - because LibreElec (at least in its Leia iteration) seems to have problems with NFS.

It works just fine in Windows, but LE fails to mount the mount points, although it can see them. I've tried your latest release just above this post and another one by adamg for S905X.

advancedsettings.xml
<pathsubstitution>
<substitute>
<from>special://profile/sources.xml</from>
<to>nfs://192.168.1.185/t/TV-Movie2/Software/Kodi/sources_nfs.xml</to>
</substitute>
</pathsubstitution>

Source example:
<video>
<default pathversion="1"></default>
<source>
<name>_Doku</name>
<path pathversion="1">nfs://192.168.1.185/t/TV-Movie2/_Doku/</path>
<allowsharing>true</allowsharing>
</source>
<video>


Unfortunately, there is nothing helpful in the debug log. It just errors out like this:

15:49:49.974 T:4093657104 DEBUG: SECTION:LoadDLL(libnfs.so.11)
15:49:49.975 T:4093657104 DEBUG: Loading: libnfs.so.11
15:49:50.001 T:4093657104 DEBUG: NFS: Context for 192.168.1.185/t/TV-Movie2 not open - get a new context.
15:49:50.023 T:4093657104 ERROR: NFS: Failed to mount nfs share: /t/TV-Movie2 (mount/mnt call failed with "")

15:50:11.103 T:3911185296 DEBUG: NFS: Context for 192.168.1.185/d/TV-Movie not open - get a new context.
15:50:11.130 T:3911185296 ERROR: NFS: Failed to mount nfs share: /d/TV-Movie (mount/mnt call failed with "")


The NFS server software is HANEWIN NFS Server if that is of interest. Any idea what can be done? Thanks in advance!


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - fritsch - 2017-12-30

For the boosted shader performance (Lanczos3 Optimized and Spline36 Optimized) the mesa environment variable needs to be set to e.g. 4.5 or lower (at least 4.0) to use this code path: 
Code:
export MESA_GL_VERSION_OVERRIDE=4.5

On LE that should go (on supported devices) into the systemd startup script


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - HeresJohnny - 2017-12-30

I've been investigating the NFS problem some more and it seems that I've found a solution. Rather than it being a problem of LE it seems to be a slight incompatibility of how Windows and Linux treat NFS mount points. Windows is more forgiving, but Linux seems to have a problem if the mount point is IP based, without an alias.

My original mount point:
d:\TV-Movie -public
resulting in a path nfs://IP/d/TV-Movie

With this modification LE is able to parse the mount point as well:
d:\TV-Movie -public -name:TV-Movie
resulting in a path nfs://IP/TV-Movie

Hope this helps other users.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - wheemer - 2017-12-31

(2017-12-30, 17:26)fritsch Wrote: For the boosted shader performance (Lanczos3 Optimized and Spline36 Optimized) the mesa environment variable needs to be set to e.g. 4.5 or lower (at least 4.0) to use this code path: 
Code:
export MESA_GL_VERSION_OVERRIDE=4.5

On LE that should go (on supported devices) into the systemd startup script 
 I'm curious about this as I would like to try to see if it has any affect on my horizontal tearing issue.

Might you be able to explain further how to add this to my test box? I tried to figure it out but didn't get far.

Thanks


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2017-12-31

(2017-12-31, 00:03)wheemer Wrote:
(2017-12-30, 17:26)fritsch Wrote: For the boosted shader performance (Lanczos3 Optimized and Spline36 Optimized) the mesa environment variable needs to be set to e.g. 4.5 or lower (at least 4.0) to use this code path: 
Code:
export MESA_GL_VERSION_OVERRIDE=4.5

On LE that should go (on supported devices) into the systemd startup script 
 I'm curious about this as I would like to try to see if it has any affect on my horizontal tearing issue.

Might you be able to explain further how to add this to my test box? I tried to figure it out but didn't get far.

Thanks

You can enable the option by running the following commands:
Code:
wget -q http://ix.io/Dzp -O/storage/.config/system.d/kodi.service && systemctl daemon-reload && reboot

However as this is a non-standard and currently unsupported setting, if you have issues please start a new thread.

We're not sure how best to integrate this change (if at all) in LibreELEC, as it may not not be suitable for all hardware.