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) - Devil-Strike - 2018-08-28

@Milhouse so you say hevc in Netflix should works? tried allot of time to get hevc(Apollo lake should work) under Netflix working but it just hangs when I try to start a serie, not that this is a big problem because h264 works just fine.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-08-28

(2018-08-28, 20:18)Devil-Strike Wrote: @Milhouse so you say hevc in Netflix should works? tried allot of time to get hevc(Apollo lake should work) under Netflix working but it just hangs when I try to start a serie, not that this is a big problem because h264 works just fine.

No, I'm not saying 4K HEVC should work - I'm only saying 4K HEVC doesn't work for me as the CPU software decode is too much for my i5 Skylake. I only see 100% activity on 1 core (and eventually 95C temps that result in CPU throttling) when trying to play a 4K HEVC stream, so even a more powerful i7/i9 CPU may struggle but perhaps with adequate cooling and if you wait long enough you might see a few frames.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-08-28

Weekly Linux 4.19-rc1 build #0827x: Generic

Packages disabled/not included:

DVB Driver Addons (CrazyCat incompatible with 4.19-rc)
Known issues:

RTL8188EU, RTL8192CU/DU/EU, RTL8812AU: driver changes untested
xf86-video-nvidia: driver changes untested

The out-of-tree Realtek WiFi drivers have been patched to work with this kernel - confirmation the changes are correct would be nice.

VC-1 videos play back at 1fps with the nvidia-legacy driver - not sure about the other nvidia driver, which has had to be patched (Intel NUC VC-1 playback is fine).

Some BIOS messages appear early in the console before the splash. Possibly some IO (network) issues too, ie. low perf (maybe that explains the VC-1 issue).

Early days...

Edit: It looks like VC-1 playback is fine - the problem with my Revo 3700 is that after a suspend and then resume the network comes up at 10Mb/s half duplex (should be 1Gb/s Full, as it is on first boot) hence the stutter during playback. My NUC doesn't have this problem. Hopefully it will be fixed in a later rc...


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-08-28

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

SHA256 Checksum: 99d6ec4130e762cc4127d5b2b5c7879cdf2f7f62f73f78d86a166fceb312216c (Generic)

# uname -a
Linux NUC 4.18.5 #1 SMP Tue Aug 28 21:19:57 BST 2018 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20180828211814-#0828-ga588776 [Build #0828]

# Kodi version
(18.0-BETA2 Git:702c2eb). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (a588776, changelog) and tip of XBMC master (702c2eb, changelog) with the following modifications: Build Highlights:
  1. [cleanup] NetworkBase and NetworkInterface refactoring
Build Details:
  1. LibreELEC.tv:
    • mariadb-connector-c: update to 3.0.6 (PR:2933, 1 commit, 2 files changed)
    • mpd: update to 0.20.21 (PR:2928, 2 commits, 3 files changed)
    • linux: fix Module.symvers generation (PR:2915, 1 commit, 1 file changed)
    • oscam update (PR:2926, 2 commits, 3 files changed)
    • xf86-video-nvidia: update to xf86-video-nvidia-390.87 (PR:2935, 1 commit, 2 files changed)
    • linux: replace ancient rc6 decode hack with proper fix (PR:2923, 1 commit, 2 files changed)
    • kodi: fix CEC not turning TV off on exit (PR:2934, 1 commit, 1 file changed)
    • Slice/Slice3: fix device tree overlays (PR:2917, 1 commit, 4 files changed)
    • linux RPi: replace ancient rc6 decode hack with proper fix (PR:2938, 1 commit, 2 files changed)
    • kodi: next (Sept || kodi bump) (PR:2909, 8 commits, 24 files changed)
    • scripts/extract: improve tar file handling (PR:2929, 1 commit, 1 file changed)
    • config/functions: clean up recursion test (PR:2907, 1 commit, 1 file changed)
    • scripts/image: use maximum lzo and zstd compression level for images (PR:2892, 1 commit, 1 file changed)
  2. XBMC:
    • [PVR] OSD: Make seek using mouse working. (PR:14363, 1 commit, 4 files changed)
    • [pvr] Persist series link EPG tag attributes to database (PR:14339, 1 commit, 2 files changed)
    • [videoplayer] GUIInfoProvider: Add subtitle info to the cache. (PR:14360, 2 commits, 11 files changed)
    • [PVR] trac18007: PVRDialogChannelsOSD: Fix crash after accessing m_ve (PR:14366, 1 commit, 1 file changed)
    • [cleanup] NetworkBase and NetworkInterface refactoring (PR:14362, 5 commits, 10 files changed)
    • VideoPlayer: WinRenderBuffer - fix buffer state after releasing video (PR:14368, 1 commit, 1 file changed)
    • [network][windows] IPv6 preparations (PR:14369, 4 commits, 2 files changed)
    • [docs/code_guideline] Fix interface file naming convention (PR:14367, 1 commit, 1 file changed)
    • Added new api EpgEventIcon for ListItem (#14361) (702c2eb)
  3. pvr.mythtv:
    • fix gui dead lock trying to prompt for deletion of last played recording (0e2708a)
    • bump version 5.8.3 (b6a5e97)
    • build from travis fails for xcode 7.3 (3163109)
  4. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: [env] PR:2908 (perma): linux (Generic): update to linux-4.18.5



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - phunkyfish - 2018-08-29

(2018-08-27, 14:53)phunkyfish Wrote:
(2018-08-25, 19:19)fritsch Wrote:
(2018-08-25, 16:23)phunkyfish Wrote: Hah, I can’t believe that was it. Thanks Fritsch!    

Could you please play it again a bit longer with 3840x2160 with debug loggin enabled? Then after 2 minutes press some button on the keyboard and enable the OSD? We want to understand what happens, e.g. what is stuck / too slow.  
 I used advancedsettings to enable debug without the overlay. If I switch on debug logging in the GUI it adds an overlay which mitigates it. 

Here you go: http://ix.io/1llE

I would be interested to learn why the overlay makes a difference. I see similar behaviour with netflix and amazon addons regardless of setting 1920/1080 resolution in GUI.

@fritsch did this help? Need anything else?


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - dr88dr88 - 2018-08-29

(2018-08-28, 15:16)HiassofT Wrote:
(2018-08-28, 15:01)dr88dr88 Wrote:
(2018-08-25, 20:16)HiassofT Wrote:  Could you please post the outputs of
Code:
dmesg | paste
cat /proc/bus/input/devices | paste
both from a working and a non-working build?

so long,

Hias  
Below is the requested output:

working version
http://ix.io/1lr6
http://ix.io/1lr7

non working version
http://ix.io/1lr8
http://ix.io/1lr9 

The output is a bit odd, you seem to have 2 air mice / remotes / wireless keyboards connected: SAGE SAGE AirMouse (USB Vendor=400c Product=107a) and FREEWAY TECHNOLOGY RFIC-MOUSE (USB Vendor=0c45 Product=5012).

Could you connect only the problematic device so we know where to look at and post dmesg, cat /proc/bus/input/devices and in addition to that "lsusb" output on a non-working build?

so long,

Hias 
 Below the requested new logs on a non functional build with all my other input devices disconnected:

http://ix.io/1luL
http://ix.io/1luM
http://ix.io/1luN


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - basco - 2018-08-29

(2018-08-28, 20:44)Milhouse Wrote:
(2018-08-28, 20:18)Devil-Strike Wrote: @Milhouse so you say hevc in Netflix should works? tried allot of time to get hevc(Apollo lake should work) under Netflix working but it just hangs when I try to start a serie, not that this is a big problem because h264 works just fine.

No, I'm not saying 4K HEVC should work - I'm only saying 4K HEVC doesn't work for me as the CPU software decode is too much for my i5 Skylake. I only see 100% activity on 1 core (and eventually 95C temps that result in CPU throttling) when trying to play a 4K HEVC stream, so even a more powerful i7/i9 CPU may struggle but perhaps with adequate cooling and if you wait long enough you might see a few frames. 
Does this have something to do with inputstream.adaptive not being multi thread capable? If so, who should we talk to to make it use all the cpu cores? thanks


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-08-29

(2018-08-29, 14:52)basco Wrote:
(2018-08-28, 20:44)Milhouse Wrote:
(2018-08-28, 20:18)Devil-Strike Wrote: @Milhouse so you say hevc in Netflix should works? tried allot of time to get hevc(Apollo lake should work) under Netflix working but it just hangs when I try to start a serie, not that this is a big problem because h264 works just fine.

No, I'm not saying 4K HEVC should work - I'm only saying 4K HEVC doesn't work for me as the CPU software decode is too much for my i5 Skylake. I only see 100% activity on 1 core (and eventually 95C temps that result in CPU throttling) when trying to play a 4K HEVC stream, so even a more powerful i7/i9 CPU may struggle but perhaps with adequate cooling and if you wait long enough you might see a few frames. 
Does this have something to do with inputstream.adaptive not being multi thread capable? If so, who should we talk to to make it use all the cpu cores? thanks

That, or it's the widevine library that is single threaded.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - fritsch - 2018-08-29

(2018-08-29, 06:55)phunkyfish Wrote:
(2018-08-27, 14:53)phunkyfish Wrote:
(2018-08-25, 19:19)fritsch Wrote: Could you please play it again a bit longer with 3840x2160 with debug loggin enabled? Then after 2 minutes press some button on the keyboard and enable the OSD? We want to understand what happens, e.g. what is stuck / too slow.  
 I used advancedsettings to enable debug without the overlay. If I switch on debug logging in the GUI it adds an overlay which mitigates it. 

Here you go: http://ix.io/1llE

I would be interested to learn why the overlay makes a difference. I see similar behaviour with netflix and amazon addons regardless of setting 1920/1080 resolution in GUI. 

@fritsch did this help? Need anything else? 
 I did not have the time to look. Busy private life at the moment. Will try over the weekend but cannot promise anything. Thanks for the information!


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Pienoet - 2018-08-29

@Milhouse is it possible to add experimental splash video for RPi on my nuc?

I like the new splah video on my rpi3b+

I wonder if this is possible to do this on my nuc?

Thanks!


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-08-30

(2018-08-29, 23:36)Pienoet Wrote: @Milhouse is it possible to add experimental splash video for RPi on my nuc?

I like the new splah video on my rpi3b+

I wonder if this is possible to do this on my nuc?

Thanks!

It's possible, yes, but it won't be easy. That's why it remains an "experimental" (ie. just-for-fun) feature on the RPi and is unlikely to be merged as it's not something that can be supported by all other LibreELEC projects (x86_64, Amlogic, Rockchip, and unknown future hardware/devices etc.).

The thing is that the RPi has always had a very simple OMX-based h264 video player available with GPU acceleration, and in order to add splash video support for x86_64 we'd need a very simply hardware accelerated h264 video player too. When you consider that we'd need to support all the various x86_64 video drivers plus video APIs (Intel/AMD VAAPI, as well as Nvidia/AMD VDPAU etc.) AND either framebuffer or x11/Wayland window managers it's no longer a simple task (and unlikely to be a 223 line programme as it is for RPi!)

And then we'd need the same kind of "simple hardware accelerated video player" for all of the Rockchip and Amlogic devices, and any other devices we may support in future, and I've no idea if that's possible for the current devices let alone future devices (I suspect it's not possible).

And decoding the video in software isn't really an option as the idea is that the splash video is played "for free" while Kodi loads - software decode would steal cycles from the CPU which is working hard to bring up the rest of the LibreELEC OS and finally the Kodi application.

Besides, on x86_64 LE and Kodi typically starts so quickly that a splash video would significantly slow down the startup process. The startup video is 14 seconds long and a typical RPi3+ (with fast SD card) takes about 11-12 seconds for Kodi to get to the point where it is ready to display the Kodi splash or - if the kodi splash is disabled - the Kodi GUI. Kodi will wait for the splash video to play out before showing the Kodi splash image or Kodi GUI, and on an RPi3+ the splash video will delay the appearance of the Kodi splash/GUI by up to 2 seconds. An RPi3 will be slower, and there is unlikely to be any delay to Kodi resulting from the video as Kodi will not be ready before the video ends (what you'll have is a period of black screen between the video ending and the Kodi splash/GUI appearing). With RPi2, RPi1 and RPi0 the period between video ending and Kodi splash/GUI appearing will be even longer.

With x86_64, adding a splash video would mean that Kodi is now always delayed by several seconds waiting for the video to end as Kodi generally starts so much more quickly than even an RPi3+ - on my i5 Skylake NUC with nvme, the Kodi splash image is never seen (even though it is enabled) as it is replaced by the Kodi GUI almost instantly, which itself only appears _after_ my computer monitor has finished changing refresh rate!

There has been discussion about adding splash video support to Kodi (by which I mean that someone has asked "wouldn't it be nice if we could do this" and other people said "yes"), which would work on all platforms, but this isn't ideal (IMHO) as now there will be a long delay while the OS loads (where nothing happens - just the LibreELEC splash image), then the Kodi application loads, and instead of displaying the GUI it plays a video for several seconds, only to THEN display the Kodi GUI. Perhaps on RPi we could use the OS splash video support which interleaves the splash video playback with Kodi startup, but on all other systems we use the "native" Kodi splash video feature. But as of right now, Kodi splash video support is not even on the horizon.

tl;dr: I added the RPi splash video for a couple of reasons - it was easy to do, and there is time to kill while waiting for Kodi to load on slower ARM systems. Neither reason is true for x86_64, nor is the first reason likely to be true for other non-RPi systems.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-08-30

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

SHA256 Checksum: ae29aa4edbed6b66e613aec21d8831cf95e7263b8487a10aca80713043bbd1d2 (Generic)

# uname -a
Linux NUC 4.18.5 #1 SMP Thu Aug 30 03:02:40 BST 2018 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20180830030104-#0829-g6f6f5e7 [Build #0829]

# Kodi version
(18.0-BETA2 Git:99a8371). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (6f6f5e7, changelog) and tip of XBMC master (99a8371, changelog) with the following modifications: Build Highlights:
  1. Updated dvb-firmware 1.3.1
  2. [videoplayer] Reduce the number of GetSubtitle() calls a bit.
  3. Show EPG image on Dialog Channel Guide
  4. Updated pvr.mythtv with GetStreamTimes support
Build Details:
  1. LibreELEC.tv:
    • linux, kodi: remove PKG_SOURCE_DIR, add PKG_SOURCE_NAME (PR:2939, 2 commits, 2 files changed)
    • update dvb addons (PR:2872, 11 commits, 50 files changed)
    • chrome: don't copy libs to toolchain (PR:2918, 3 commits, 17 files changed)
    • Kodi: use toolchain nm for generating wrapper.def (PR:2921, 2 commits, 3 files changed)
    • WeTek_Core: disable dvb driver addons (PR:2940, 1 commit, 1 file changed)
    • dvb-firmware: update to 1.3.1 (PR:2941, 1 commit, 1 file changed)
  2. XBMC:
    • [videoplayer] Reduce the number of GetSubtitle() calls a bit. (PR:14365, 1 commit, 3 files changed)
    • Some minor MMAL improvements (PR:14337, 5 commits, 6 files changed)
    • PythonInvoker: fix thread termination check (PR:14356, 1 commit, 1 file changed)
    • Fix access to music information from menu and shortcut key (PR:14364, 1 commit, 4 files changed)
    • Added PVR.EpgEventIcon guiinfo label (PR:14372, 1 commit, 3 files changed)
    • Show EPG image on Dialog Channel Guide (PR:14355, 1 commit, 1 file changed)
  3. pvr.mythtv:
    • processing task by dedicated thread (8b3e9e8)
    • bump version 5.8.4 (62b5c04)
    • implement GetStreamTimes from API 5.8 (3bff33b)
    • bump version 5.8.5 (6482442)
  4. pvr.zattoo:
    • Fix loading details of more than 200 recordings (8de69a1)
  5. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: [env] PR:2908 (perma): linux (Generic): update to linux-4.18.5
    • Updated: [env] PR:2913 (perma): linux (RPi): update to linux-4.18.4
    • Added: [env] PR:2904 (perma): zlib: add neon optimizations
    • Added: [env] PR:2916 (perma): ffmpegx and tvh



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - phunkyfish - 2018-08-30

(2018-08-29, 20:59)fritsch Wrote:
(2018-08-29, 06:55)phunkyfish Wrote:
(2018-08-27, 14:53)phunkyfish Wrote:  I used advancedsettings to enable debug without the overlay. If I switch on debug logging in the GUI it adds an overlay which mitigates it. 

Here you go: http://ix.io/1llE

I would be interested to learn why the overlay makes a difference. I see similar behaviour with netflix and amazon addons regardless of setting 1920/1080 resolution in GUI. 

@fritsch did this help? Need anything else?   
 I did not have the time to look. Busy private life at the moment. Will try over the weekend but cannot promise anything. Thanks for the information!  

Just let me know whenever suits. Now that I’m aware of this I’ve noticed it happens a lot more than I thought. Low res videos show it more than ones that are close to 1080.

Every time the overlay removes the problem. The overlay also works to fix the issue when using the Amazon and Netflix addons even though those streams are 720/1080p.

Also confirmed on a j5005 as well as N5000. Happy to provide any debug logs you need.


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-08-30

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

SHA256 Checksum: d6c96dec39dc59be66f1559ecddab896d9528788779b30ea80b0430424b85a80 (Generic)

# uname -a
Linux NUC 4.18.5 #1 SMP Thu Aug 30 21:16:15 BST 2018 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20180830211442-#0830-g9bcfef4 [Build #0830]

# Kodi version
(18.0-BETA2 Git:af7276c). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (9bcfef4, changelog) and tip of XBMC master (af7276c, changelog) with the following modifications: Build Highlights:
  1. [bluray] Usability improvements and some refactoring
Build Details:
  1. LibreELEC.tv:
    • vdr-plugin-xmltv2vdr: add buildfix patch (PR:2944, 1 commit, 1 file changed)
  2. XBMC:
    • [guiinfo] Fix String.IsEqual if second parameter is a listitem in a given container (PR:14375, 1 commit, 2 files changed)
    • Improve wrapper.def generation (PR:14354, 1 commit, 1 file changed)
    • [bluray] Usability improvements and some refactoring (PR:14374, 7 commits, 4 files changed)
  3. inputstream.adaptive:
    • [Android] remove MediaDRM::KeyReqest::getRequestType from log for L devices (997abf6)
  4. Additional commits/pull requests/changes not yet merged upstream:



RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - TimoJ - 2018-08-31

(2018-08-26, 09:42)TimoJ Wrote: Kodi still has this weird bug: if I go to Movies/Titles and scroll the list with key pressed down, scrollspeed is too fast, looks like it goes double the speed than it should. But when I go to TV Shows/Titles and scroll the list, speed is normal. Using just keyboard to test this. Same problem also if I go to my movies folder via Videos/Files. And again it's only movies folder that has this effect. Changing view type has no effect to this.

So what causes this?
Anyone? I slowed down keyboard repeat rate to have better understanding of what is happening. Looks like the movie list starts to jump in pages soon after curson up/down key is pressed down. So there is no way to move cursor just few lines with cursor key pressed down, you always have to single tap the key or repeat kicks in and page jumping starts Sad  Where does this buggy function come from? And why only movie list is effected? Still, inside movies set listing this works correctly.