• 1
  • 218
  • 219
  • 220(current)
  • 221
  • 222
  • 355
v18 LibreELEC Testbuilds for x86_64 (Kodi 18.0)
(2018-05-03, 20:46)blob810 Wrote: Here are my settings and a debug log.
What kind of remote(s)/remote receiver(s) are you using?

I see 2 lines relating to power buttons in the log, first from a keyboard(-like) device:
Code:
20:40:18.558 T:140444541241472   DEBUG: Keyboard: scancode: 0x7c, sym: 0x0140, unicode: 0x0000, modifier: 0x0
20:40:18.558 T:140444541241472   DEBUG: HandleKey: power (0xf0de) pressed, action is ActivateWindow(ShutdownMenu)

and then about a second later another one from a remote that has been picked up by eventlircd:
Code:
20:40:19.838 T:140444530267904   DEBUG: LIRC: - NEW 74 0 KEY_POWER devinput (KEY_POWER)
20:40:19.847 T:140444541241472   DEBUG: HandleKey: rewind (0xc4) pressed, action is ShutDown()

What exactly did you do when you created the log? I have no idea how a second power button press on a different input could be generated more than a second later by anything on the system.

For remote receivers that are not run through eventlircd (which are a couple of RF, BT and a few odd IR remote receivers) and are seen by kodi as "keyboards" getting the shutdown menu is expected behaviour since the systemd-logiind change.

Before the systemd change your PC would unconditionally just shut down, after it kodi handles the power event - and the default action there for "keyboard-like" remotes (and with the eventlircd change also the PC's power button) is to display the shutdown menu. The default action for the power button events received by kodi from (lirc) remotes differs, it's doesn't display the menu but just shuts down. Don't ask me why the default is different.

So, except for the mysterious second power button event everything looks like it should be, if you don't like the shutdown menu just configure kodi to not show it. Create a .kodi/userdata/keymaps/keyboard.xml with the following contents:
Code:
<keymap>
  <global>
    <keyboard>
      <power>ShutDown()</power>
    </keyboard>
  </global>
</keymap>

so long,

Hias
Hi HiassofT,

thanks for your fast reply.

in the log file I only pressed the power button once. As IR-Sensor I have a "Nanu SE-IR Infrared RC6". My Remote is a Harmony 650 configured as Microsoft HTPC. 
I tried the solution with the keymap.xml from your post. This is working for me. Now my HTPC is shutting immediately down when I press the power button on the Logitech harmony. 

My question is why you change the behavior when pressing the power button on the remote. Because before the PR it was already working, without a keymap file. 

thank you
(2018-05-04, 15:26)blob810 Wrote: My question is why you change the behavior when pressing the power button on the remote. Because before the PR it was already working, without a keymap file. 
I didn't change the behaviour of the power key, the kodi default is to show the shutdown menu.

Previous versions had a bug that would unconditionally shutdown your system when you press the power button and prevented kodi from reacting on it at all. So people coudn't get to the shutdown menu at all and kodi couldn't initiate a graceful shutdown as it should.

so long,

Hias
(2018-05-04, 01:15)Milhouse Wrote:
(2018-05-02, 19:42)Nekromantik Wrote: @Milhouse did you get chance to look at my crash log?

Sorry missed your post. Looks like it might be Python related, can you test with tonight's build which includes more Python re-use fixes? 
Will try that thanks
(2018-04-29, 20:27)Milhouse Wrote:
(2018-04-29, 19:32)blob810 Wrote: After update to build #0425 my makemkv addon-script doesn´t work anymore. With build #0424 everything is fine. In the debug log it says only that the bluray is aacs protected and playback doesn´t start.
The addon was build with this Package.mk

You'll need to contact the add-on maintainer and ask if it is compatible with ffmpeg-4.0 - most likely it needs to be bumped and rebuilt against ffmpeg-4.0. 
 I recompiled the add-on with the updated FFmpeg 4, and its working now. Thank you.
New LibreELEC.tv Leia build #0504: Generic
(Supercedes previous build)

SHA256 Checksum: d49d421a8e27b30ec6353dd5b6e1b6617be95835ce8b6f991c2d133a65433d20 (Generic)

text:
# uname -a
Linux NUC 4.14.37 #1 SMP Sat May 5 01:16:35 BST 2018 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20180505011315-#0504-g8463ee0 [Build #0504]

# Kodi version
(18.0-ALPHA2 Git:eb1e22e). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (8463ee0, changelog) and tip of XBMC master (74ebeb3, changelog) with the following modifications: Build Highlights:
  1. Drop PR2572 (update dvb addons) due to build issues
  2. libvdvdread/nav/css bumps to Leia (alpha 3)
Build Details:
  1. LibreELEC.tv:
    • mesa: update to mesa-18.0.2 (PR:2678, 1 commit, 1 file changed)
    • RPi, Generic: backport proposed patch to reduce IR latency (PR:2623, 1 commit, 2 files changed)
  2. XBMC:
    • [fix] handle multiselect addon setting (PR:13847, 1 commit, 1 file changed)
    • Log CURL HEADER_IN and message up to 255 chars if component libCURL l (PR:13821, 1 commit, 1 file changed)
    • limit visibility of CGetDirectoryItems to local file (PR:13850, 1 commit, 3 files changed)
    • fixed: use the dyn url for protocol check if available (PR:13851, 1 commit, 1 file changed)
    • [guiinfo] Fix Player.IsInternetStream (PLAYER_ISINTERNETSTREAM)... (PR:13841, 1 commit, 1 file changed)
    • [fix][json-rpc] execute GUI.ActivateWindow asynchronous (PR:13852, 1 commit, 1 file changed)
    • Mode whitelist (PR:13274, 2 commits, 9 files changed)
    • osx: no limited color range on osx, fix log spam (PR:13853, 1 commit, 2 files changed)
  3. Additional commits/pull requests/changes not yet merged upstream:
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
I've been reading the forums for last day and trying to understand the current state of intel linux drives and if the current kernel versions support 4k HDR yet? Is it looking likely that we will be getting HDR for x86 libreelec? I just bought an apollo lake box for 4k HDR but didn't realise it's not really supported yet. If it's not likely to be supported in LE9 then I might just get a AMlogic S912 device or something.
Netflix users: You will need the latest version of the plugin.video.netflix add-on from Github as this version solves the recent login issues, and also the freezing issue introduced after the Busy Dialog changes in #0502. Specifically, you will need a version that includes at least this this commit.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2018-05-05, 12:28)anand_patel18 Wrote: I've been reading the forums for last day and trying to understand the current state of intel linux drives and if the current kernel versions support 4k HDR yet? Is it looking likely that we will be getting HDR for x86 libreelec? I just bought an apollo lake box for 4k HDR but didn't realise it's not really supported yet. If it's not likely to be supported in LE9 then I might just get a AMlogic S912 device or something.

The Linux kernel doesn't currently support HDR.

HDR support needs to be implemented at every step of the rendering chain - from Kodi to ffmpeg to mesa/graphics drivers and eventually the kernel etc. Once all of that is done it will be supported by LibreELEC and other Linux-based distributions.

Be careful with AMLogic as (at the time of writing) it doesn't actually support "true" HDR - AMLogic implements an 8bit-to-10bit conversion which is not HDR and in terms of visuals it doesn't compare to true HDR. Simply outputting everything at BT2020/4:4:4/10-bit (which is what AMLogic does) doesn't mean it is "true" HDR and indeed some receivers/displays object to being fed this type of fudged signal.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
New LibreELEC.tv Leia build #0505: Generic
(Supercedes previous build)

SHA256 Checksum: 99e49ea7a3440365c73e0e228f5473c54654d8ce9cd49df5d91c48ecd4f28a02 (Generic)

text:
# uname -a
Linux NUC 4.14.39 #1 SMP Sat May 5 21:24:51 BST 2018 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20180505212132-#0505-g8463ee0 [Build #0505]

# Kodi version
(18.0-ALPHA2 Git:eb1e22e). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (8463ee0, changelog) and tip of XBMC master (78af1d6, changelog) with the following modifications: Build Highlights:
  1. New 4.14.39 kernel
  2. Python reuse fixes
  3. [music]Fix fanart for library items on playback from file view
Build Details:
  1. XBMC:
    • [win10] bump minimal required SDK version to 10.0.16299 (PR:13849, 9 commits, 18 files changed)
    • [fix][video] load correct multi episode if info tag has season & episode set (PR:13855, 1 commit, 1 file changed)
    • VideoPlayer: flush renderManager when hiding video (PR:13824, 2 commits, 1 file changed)
  2. Additional commits/pull requests/changes not yet merged upstream:
    • Updated: [env] PR:2680 (perma): kodi: mid-May 2018
    • Updated: [env] PR:2682 (perma): linux: update to linux-4.14.39
    • Updated: [pkg] PR:13814 (perma): Reusepython
    • Added: [pkg] PR:13854 (perma): [music]Fix fanart for library items on playback from file view
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2018-05-05, 22:53)Milhouse Wrote:
(2018-05-05, 12:28)anand_patel18 Wrote: I've been reading the forums for last day and trying to understand the current state of intel linux drives and if the current kernel versions support 4k HDR yet? Is it looking likely that we will be getting HDR for x86 libreelec? I just bought an apollo lake box for 4k HDR but didn't realise it's not really supported yet. If it's not likely to be supported in LE9 then I might just get a AMlogic S912 device or something.

The Linux kernel doesn't currently support HDR.

HDR support needs to be implemented at every step of the rendering chain - from Kodi to ffmpeg to mesa/graphics drivers and eventually the kernel etc. Once all of that is done it will be supported by LibreELEC and other Linux-based distributions.

Be careful with AMLogic as (at the time of writing) it doesn't actually support "true" HDR - AMLogic implements an 8bit-to-10bit conversion which is not HDR and in terms of visuals it doesn't compare to true HDR. Simply outputting everything at BT2020/4:4:4/10-bit (which is what AMLogic does) doesn't mean it is "true" HDR and indeed some receivers/displays object to being fed this type of fudged signal.  
 Thanks for response. 

In terms of the rendering chain, what has been implemented for necessary requirements for HDR. Kodi (18 Yes) to ffmpeg (yes? no?) to mesa drivers (yes? no?) and kernel (no).

Thanks that's good to know about AMlogic. So they dont actually do true HDR, isn't that a bit misleading on all the threads that recommend it? Is there a source I can read more about AMLogic converting 8bit-to-10bit conversion. 

My intel setup is currently perfect except HDR and auto switching, when going from 1080p in UI to 2160p Video back to 1080p in UI, the video signal is lost and have to unplug HDMI in and out to get picture back. Hopefully that is fixed in LE9.
(2018-05-06, 01:36)anand_patel18 Wrote:  Thanks for response. 

In terms of the rendering chain, what has been implemented for necessary requirements for HDR. Kodi (18 Yes) to ffmpeg (yes? no?) to mesa drivers (yes? no?) and kernel (no).

Thanks that's good to know about AMlogic. So they dont actually do true HDR, isn't that a bit misleading on all the threads that recommend it? Is there a source I can read more about AMLogic converting 8bit-to-10bit conversion. 

My intel setup is currently perfect except HDR and auto switching, when going from 1080p in UI to 2160p Video back to 1080p in UI, the video signal is lost and have to unplug HDMI in and out to get picture back. Hopefully that is fixed in LE9.

Your first question: Not my part of the ship, really. It's been mentioned several times on this forum that Linux doesn't support HDR. I'm not sure when it will. It also depends on the hardware, as pre-Apollo Lake hardware isn't capable of HDR, and there continue to be question marks about Apollo Lake and even later hardware.

I suspect most of the threads punting AMLogic as supporting HDR aren't aware of how AMLogic currently does it (and have done it badly). Sure, it looks better (or at least different) than SDR, but it's not true HDR. You'll need to find an AMLogic developer that is knee deep in the AMLogic kernel, I'd suggest looking at what OSMC are doing or asking on their forum as they're trying to do it right but it's a work-in-progress (@Sam.Nazarko if you want to chip in here, feel free!)

Your Intel bug: I don't know if it will be fixed in LE9, you might need a mainline kernel which isn't currently targeted for use in LE9.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Thanks for the ping Milhouse.

AMLogic HDR is broken overall, but it works in OSMC on the Vero 4K. We continue to improve it and work on some of the corner cases. 
Currently, you need to manually enable HDR. Our autoswitching detection is hit and miss, but we're aware of this and fixing this up. I'm aware that another distribution is using some of our fixes; but they're not implementing them on the kernel side as well (just Kodi) which is resulting in some bad reports. 

In the interest of transparency, we don't pass MaxCLL / MaxFall at this time however. When I tested passing these values through, I could not notice a difference on many displays, including the highly acclaimed LG OLED B7s. 

Happy to go in to more detail if you have questions.

Sam
(2018-05-06, 03:42)Sam.Nazarko Wrote: In the interest of transparency, we don't pass MaxCLL / MaxFall at this time however. When I tested passing these values through, I could not notice a difference on many displays, including the highly acclaimed LG OLED B7s. 
How did you verify that the MaxCLL/MaxFALL values were indeed present in the static HDR metadata of the output signal?
(2018-05-05, 22:53)Milhouse Wrote: Be careful with AMLogic as (at the time of writing) it doesn't actually support "true" HDR - AMLogic implements an 8bit-to-10bit conversion which is not HDR and in terms of visuals it doesn't compare to true HDR.
I thought this didn't apply to the S912 SoC.
  • 1
  • 218
  • 219
  • 220(current)
  • 221
  • 222
  • 355

Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for x86_64 (Kodi 18.0)24