Have the same issue on my NUC11TN no HD Passthrough audio, then audio does not work until a reboot. All other audio formats seem fine.
Is anyone else having this problem? I don't think this is specific to this particular build, I am also experiencing it with the nightly.
Okay, I updated from LE10 to the latest Generic nightly and the Sound Devices changed from HDMI Port #5 to DisplayPort #0. Now the getedid script works again, thank you!
I guess the LE10 Kernel is too old for the NUC11?
Anything new on this topic?
I also have the NUC11PAHi5 and DP-3 shows as connected when I use the HDMI port. getedid does not work as well as manual edit, the display just stays black.
Thanks! I didn't even know they had a mode to grab from "external" video sources. Makes sense I guess...
This would be the corresponding feature request for anyone interested.
There is progress going on in this pull Request at hyperion.ng: Media Foundation/V4L2 grabber ... by Paulchen-Panther · Pull Request #1119 · hyperion-project/hyperion.ng · GitHub
It looks like they are implementing a v4l2 grabber.
Thank you Team Libreelec for this writeup, I think we all appreciate the details on the state of the various platforms.
Also thank you for beeing bold enough to streamline the number of supported platforms - I think we will all benefit from a codebase which is easier to maintain in the future - even if it means getting rid of some of our beloved older devices...
You can always get a Pi4 for 40 bucks and have good performance and support for the years to come. 
OK, I think I got it. I had to restart the video ~20 times before it happened. Maybe you could confirm its a driver bug before I file it with them?
Kodi.log: RfDH
dmesg: eYSc
Unfortunately, its only the last part of the dmesg, I guess the buffer was too small for that.
LibreELEC:~ # uname -m
x86_64
LibreELEC:~ # uname -r
4.13.4
LibreELEC:~ # xrandr --verbose | paste
http://sprunge.us/effM
LibreELEC:~ # dmesg | paste
http://sprunge.us/eYSc
LibreELEC:~ # cat /sys/class/drm/card0/error | gzip > error.gz
LibreELEC:~ # echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom
LibreELEC:~ # cat /sys/devices/pci0000:00/0000:00:02.0/rom > vbios.dump
LibreELEC:~ # echo 0 > /sys/devices/pci0000:00/0000:00:02.0/romThank you for your answer!
I can workaround the bug by disabling MPEG-2 VAAPI. Thats what I have to do since the last couple of versions 
If I remember correctly I tried with the build fritsch provided in the kodi trac and it worked with this one. Wouldn't this one hang too if it was a driver issue?
How do I adapt the kernel command line? Is this something I can do at boot? Can it be done in a live environment? I like to boot "live" to have the stock image for testing.
Can I append them like this in syslinux.cfg?
LABEL live
KERNEL /KERNEL
APPEND boot=UUID=3108-2154 live quiet tty vga=current drm.debug=0x1e log_buf_len=2Mjust tried this, at least they show up in proc/cmdline so I guess thats fine. Running the test now..
mraction If you have the same problem, maybe you could also test with the video file I provided and a clean install (or "live" boot) of Libreelec. Post a debug log and maybe we can get this thing worked out
I would really like to get to the bottom of this. If there is anything else I can test or provide let me know...
Any news on this?
Can I try anything else?
Hello,
I have been experiencing a problem for some time now: Kodi freezes when I watch SD content with VAAPI enabled. I posted about it here and we hunted it down to beeing a kernel bug.
It does not happen on Ubuntu 16.04.1 LTS, it does not happen on a downgraded kernel version of Libreelec (the one posted on the TRAC ticket by fritsch).
LE 9 Debug Log: DiPD dmesg: LHCL
LE 8.1.1 Debug Log: OWYL
LE 8 Debug log: UIQO
Debug log Kodi beta3: WCDf
dmesg after the freeze: HdUP
gdb debug: MNhA
File to reproduce: Die Ruhrpottwache-SAT.12017-02-1712-59.ts?dl=1
Remark from fritsch:
From my first analysis it looks like something mesa intel driver vs. xserver vs. egl
Thank you for looking into this, let me know if I can help any further.
Here is a freeze-log from libreelec BETA 3: RMgA
I set the recording profile to "pass" in tvheadend and did a recording: Die Ruhrpottwache-SAT.12017-02-1712-59.ts?dl=1
I played it several times, the first time it froze, but the CPU load numbers and memory on top still changed and playback recovered after a while (First time that happened btw). Next time I played it, kodi completely froze. There is no crashlog because kodi is still running, it just doesn't react to any input. (The sigterm is from when I shut it down after ~15 minutes)
Here is another freezing log from when I played the file through the file system, no tvheadend involved (I had to restart it several times)
QcfM
As the TRAC tickets states, this is exactly what I am doing now, thank you. This is still a valid bug and I still would like to use hardware decoding.
Same with BETA 2, aMTI
Can anyone please help me with this, it seems like the problem was already localized by fritsch (kernel regression). I would be glad to try some builds and help solving this problem...
Maybe someone can also move this to bug reports.