Odd video menuing problem with v18

  • I am having a problem with v18 code. I've seen it in earlier v18 releases but have been dealing with other playback issues which are now resolved. The problem remains in the most current release. I have an 8th generation Intel NUC (8i7BEH) connected directly to my Samsung F9000 TV running HDMI 2.0 3840x2160 @ 60 fps (although I don't believe the resolution and refresh rates don't seem to make a difference). Also connected to my TV is a Roku Ultra device on another HDMI input. The problem can easily be reproduced. When the problem occurs the text on any menu disappears and I get is the background Kodi menus without text. This includes hitting the info button, the codec information when a video is playing or even the basic video menus to navigate my library. It is also independent of the skin. I can reproduce this with either Confluence or Estuary. Here's the sequence of steps to reproduce:


    1. I am viewing the NUC / Kodi on my Samsung TV, generally playing a video but it doesn't seem to matter what I am doing.

    2. I switch away on the Samsung to view the Roku device. The NUC stays powered up as-is.

    3. I switch back to the NUC and play a video.

    4. While playing a video I hit any overlay screen output like the Info button, Menu button, I skip the video or view the codec info.

    5. At this point whatever comes up in #4 comes up with the background and any associated images but the text is gone.


    Rebooting the NUC fixes the issue. Sometimes I can switch away from the NUC and switch back on my Samsung TV and the text comes back but not always. I can post a screen shot of what this looks like when it happens and a log output if it would be helpful and this hasn't been seen before. it seems like something with the HDMI output / negotiations. If I never switch away from the NUC (steps 2 and 3) the problem never occurs. Has anyone else seen this loss of menu text symptom ?

  • I've seen missing text when Kodi changes break OpenGL compatibility with the video drivers used for vmware support. I can't see how changing HDMI output and back would cause OpenGL issues, but I'm not an expert in the Xorg side of things though.


    @lrsusak, ping ^ any ideas?

  • Thanks.for looking into this. I've done additional testing and believe I have found the cause but don't have a solution. There was another thread regarding sending video out the main NUC HDMI port and sending audio out the display port. I've determined the problem started when I moved to this configuration. So what appears to be happening is that when I switch the Samsung video to watch another source Kodi sees that output go away (even though it is still physically cabled) and then only sees the display port which I am using for audio. When the problem occurs, if I pull the display port connection to the NUC the menus come back. I've enabled the Kodi blank other displays option since I really don't want or need video going out the display port but that doesn't help. What I don't think should be happening is that one output is impacting the other. I would think video outputs should be totally independent. .

    Edited once, last by jbinkley60 ().

  • Are you running the latest BIOS version in your NUC ?


    Are there any BIOS settings that would affect the HDMI & DP outputs

  • I have the latest BIOS 0056. I don't see anything in the BIOS which would align to this. I did some additional testing with my other NUC running 8.2.5 and I think what may be happening is that when my Samsung TV connects to my NUC on an HDMI connection a handshake occurs which causes LibreElec / Kodi to determine the resolution. With my 8.2.5 NUC connected straight to my TV when I switch back / forth the NUC will occasionally switch from my video setting of 3840 x 2160 @ 30 fps to 1920 x1080 @ 60 fps. If I plug the same NUC into my Yamaha receiver and then to the TV the NUC will not change resolution when I switch HDMI inputs on the receiver. So this leads me to think that if I can lock the resolution in LibreElec to what I want and not allow it to ever change (except when I change it) that this may resolve the issue. Here's a thread which sounds very similar to mine.

  • I've decided to give up on trying to use both the NUC HDMI and USB-C outputs simultaneously. I've ordered an HDMI splitter which will pass 4K @ 60fps over HDMI 2.0 for video and output video / audio @ 1080P @ 60 fps over HDMI 1.4 for my AV receiver to extract the audio. It is supposed to pass full uncompressed 7.1 audio. The user reviews show others using it to do exactly what I want. Once I receive it I'll post my results.

  • The HDMI splitter arrived and is working perfectly. The only thing I needed to do was connect the HDMI 2.0 passthrough output to my Samsung TV on splitter output 1 and the HDMI 1.4a output to my Yamaha AVR on splitter output 2. I originally had them reversed and it wouldn't work. So now I have HDMI 2.0a [email protected] 60 fps coming out of my 8th gen NUC going through the splitter and passing the same out port 1 and reducing the resolution to 1080P @ 60 fps out port 2.


    So just when I was ready to declare victory this has uncovered an interesting issue with DTS HD/MA and Tru0HD passthrough with the NUC. The short version is that the only configuration where these work with passthrough is if the NUC is connected straight to my Yamaha receiver and the video is set for 4k @ 30 fps. If I have the NUC connected to my Yamaha receiver and change the refresh rate or resolution (i.e. 1080P @ 60fps, 4K @ 24 fps etc..) the passthrough stops working for these uncompressed audio formats. So through the splitter they don't work but it appears to be a NUC / software issue and not the splitter. If I take the SSD with the LibreElec build from this NUC and put it in my older 5th gen NUC the audio passthrough works fine through the splitter. If I hook up my Vero 4K+ instead of the NUC passthrough runs tine too.


    I know there have been some threads regarding uncompressed audio passthrough with the newer NUCs but most of them have been with the 7th generation units and not the 8th gen. It feels like this may be a driver issue especially when I can break it simply by changing the resolution or refresh rate.


    Any thoughts ?

  • I'll try the Intel forums but it typically takes a number of turns with them to get responsive if you aren't running Windows 10. I was hoping someone else here had an 8th generation NUC and could tell me if they are seeing the same thing or not. I have a Windows 10 SSD with Kodi on it. I'll install it and try bitstream audio passthrough and see if I see the same thing. Hopefully I can get to that today.

  • A large percentage of NUC users run Linux builds too. I don't think many are splitting the audio and video into two different paths though. Intel recently revamped their entire Forum and dumped the old posts (as far as I can see). I'm not sure if past forum members are still there or not. I always got good help there but that was months ago before the change.

  • There are staff with 8th Gen NUC's, but more for video development than general testing. As a broad rule it often takes a few kernel iterations before support for the latest generation of NUC hardware settles down.

  • Thanks. The splitting of audio / video is less of a concern than seeing things like bitstream passthrough stops working when the video resolution changes on my gen 8 NUC and I am just plugged in direct with both audio /video going over the same connection. I'll do some more testing today and see what I find. I suspect the kernel iteration comment is spot on. With the HDMI splitter, which has full HDMI EDID support, LibreElec just sees the HDMI splitter as a single device with full 7.1 capability which works fine with the older NUC and my Vero 4K+. If I disable bitstream passthrough on the gen 8 NUC for DTS HD/MA and True HD and leave passthrough enabled for everything else then everything plays fine.

  • I see this same menu text disappearing issue with my Chromebox running v 8.95.1 and older Leia-based LE distros. I'm able to reproduce the issue with the same steps as the OP, but I don't always need to switch away from the HDMI source on the TV. I've switched back to stable 8.2.5 for now b/c I needed the box as my daily driver. If I get a chance, I'll try Beta 2 and enable debug, but I suspect OpenGL issues like Chewitt suggested.