I have not tested for long, because unfortunately the TVHeadend server on the build isnt working (requires a kernel-module which is not there - most likely due to the kernel-change?) and I needed to watch some TV
Yes, Tvheadend that was compiled for X11 version of LE doesn't work.
I compiled Tvheadend 4.2 and 4.3 that will work with my builds.
NUC6AYH has HDMI 2.0 port (MCDP2800 LSPCON), J3455 Apollo Lake SoC with Gen9 Graphics. It should be capable to support HDR in Linux.
Windows HDR support is irrelevant, Gemini Lake also doesn't support HDR in Windows.
and you cant roll back the update
In theory it should be possible with a Flashrom utility under DOS as long as somebody provides a bios dump from the same NUC.
Try to test with a short (< 2m) known good cable connected directly to a TV. Intermittent blanking in 4K modes could be caused by a bad or too-long cable.
the screen seems to go black intermittently for a few seconds and then the picture comes back on
Does this happen with all video modes or only with 4K?
NUC6AYH : No-go for HDR.
NUC7i3BN : Works with HDR (on the previous build you posted about roughly a week or two ago)
That's interesting.
According to Intel's support pages for those NUCs they use the same MCDP2800 LSPCON chip.
Can you retest NUC6AYH with the build from post #502?
Also note that there is an issue with those builds. If you turn the TV off and then on (while the NUC is connected and working) - HDR will stop working until Kodi is restarted (maybe a bug in EDID parser code).
You can install LE to a USB drive.
I'd rather not.
Master branch is almost identical to a Matrix branch at this point anyway.
Yes, that one is working.
Haven't tested it properly yet though but I did saw the HDR icon show up on my tv.
That's good news. You are the first one who reported a working HDR on older LSPCON hardware. It looks like that NUC has MegaChips MCDP2800BC LSPCON.
I uploaded an updated image.
- Linux kernel 5.12-rc4
- Kodi e04f7d6
Everything else is identical to a build from post #494.
No. I forked lrusak repo and merged kodi master branch into drmprime-2img-no-ffmpeg-bump branch.
Updated build with HDR:
Current Kodi master (83387b9)
Linux kernel 5.11.7
Mesa 21.0.0
Full-feature Intel media-driver with fixed VAAPI DI
HDR patches from Commits · lrusak/xbmc · GitHub
how can a NUC decode audio same then a 1k AV.
Very easily. If you extract the same .rar archive on a $10000 computer and on a $100 computer - the extracted content of the archive will be bit-identical on both PCs.
Same goes with lossless audio formats.
Those HBR audio formats like DTS-HD MA, Dolby TrueHD or flac are merely a lossless compression of data. It makes no difference where the decompression takes place. Bitstreaming and decoding to LPCM are just 2 different methods of delivering the same audio data to the AVR.
Bitstreaming makes sense on those devices that for whatever reason cannot decode the above mentioned formats. Since Kodi can do a lossless decode of any HBR format - the absence of bitstreaming should never be an issue.
What is the advantage of bitstreaming the audio vs.sending the decoded LPCM to AVR? Just trying to understand why people care so much about audio passthrough. I'd like to hear a valid technical reason why bitstreaming is supposed to be better than decoding to LPCM. Since Kodi can decode all known HBR audio formats and send LPCM 7.1 over HDMI I don't see a single good reason why anyone should bother with passthrough.
I stayed with using the iHD/i915 driver.
intel-vaapi-driver (i965) doesn't work at all on Tiger Lake, so you don't really have much choice 
It's been 2 years and 4 months since you opened that PR. 
Hopefully nobody would object this time if you reopen it 
Nvidia users are better off using Windows 10. Actually, my main PC is Ryzen 5 3600 with Nvidia GTX 1650 running Windows 10
Discrete graphics doesn't make sense for a dedicated LibreELEC box anyway. Low-power APUs and SoCs is what LE is all about IMO.
Not sure about the AMD situation.
AMD works fine on GBM
