Posts by RvL


    Actually, I do remember doing something to my NUC, I increased the memory allocated to the GFX in the BIOS. I cant remember what I increased it to but it was far more than the default (it was 32Mb by default), I have no idea why I did this other than "its what I would normally do with onboard GFX and I have boat loads of RAM".


    Sorry for my late reply, I realize it has been over a month.

    I've tried every possible solution in this topic. Upgraded to the latest 7.90 alpha, which didn't solve the problem. Checked every device for its CEC settings but it was disabled on all devices.

    Eventually, I found the solution to my problem. I've changed some settings in UEFI:

    • Video memory and aperture both to 512MB
    • Primary video output fixed to HDMI (instead of auto)
    • Secondary video output fixed to VGA
    • Intel Dynamic Power Technology switched off


    Too much changes to really pinpoint the exact solution but it seems to work. The current uptime is over 8 days.

    Thanks all for your support! I'm going to update to the latest beta now instead of the 7.90.010 alpha ;)


    You might want to compare with my latest extended build, it's got Linux 4.9 (drm-next-nightly) and updated mesa/xf86-video-intel drivers.


    Thanks! I'll give it a try.


    do you use CEC? Could your CEC be trying to "hibernate" the NUC thus falling over? Im running my NUC5PPYH and have had no freezing issues if that helps at all. (stable libreelec twinned with W10 + KODI dual boot)

    As far as I know, I've disabled CEC everywhere. Not my favorite protocol to say the least, with devices switching on and off at all but the right moment :). But I'll double check it just to be sure.

    Thanks! I'll give it a try and keep you updated.

    The device really freezes though. I can't ping the device for instance. Sometimes I can still see the last screen, but in most cases the screen is simply black. AVR tells me there is a HDMI link at that moment.

    Okay, update

    I dumped the EDID as you suggested but unfortunately the NUC keeps crashing.

    Latest kodi.old.log (crashed) : cSKE
    Current kodi log (still active): AMci

    I'd still like to dump the kernel messages to a file if possible. But is that possible?


    Might be, yes

    So I guess it does not freeze. I guess there might be a handhake issue.

    I would suggest to dump the EDID like explained here: Custom EDID - LibreELEC

    After that you shouldn´t have a problem at switching devices on or off.

    Thanks! I'll give it a try and keep you updated.

    The device really freezes though. I can't ping the device for instance. Sometimes I can still see the last screen, but in most cases the screen is simply black. AVR tells me there is a HDMI link at that moment.

    Hi all,

    I've recently switch to LibreELEC from OpenElec. Mostly because the update frequency of LibreELEC is a bit higher, but also because I was hoping it would fix the problem I'm having with my system.

    I'm using a NUC5CPYH (Celeron n3050 based) to run LibreELEC, latest stable. When playing videos, everything works just fine, even if I watch videos all day. The problem arises when the system is idle for a longer period of time. My NUC is always switched on because I want to be able to connect to the system from Android. But after a while, the system completely freezes. The only way to revive the system is by hard-switching it off (keeping power button pressed for a couple of seconds) and restart the system.

    The system has 4GB RAM memory on board and LibreELEC is installed on a hard drive, connected to the SATA connector on board. Also, a external HDD is connected to USB. System uses WiFi to communicate with the rest of the network.

    Complete debug log from before the latest restart can be found here: MaAB

    Only thing I see (without too much knowledge of Kodi and/or LibreELEC) is something about not being able to open a certain movie. Just to be sure, I've removed this movie.

    But somehow I don't suspect it has anything to do with Kodi. Reading the kernel log is rather impossible because the system is completely inresponsive after the crash. Is it possible to output dmesg to a file instead the standard buffer?

    Any ideas on this? Could it be memory related? I've ran memtest86 after installing the module (common practice for me) and after a couple hour it was still free of errors.

    Kind regards,
    RvL