Update to a current LE13 nightly image from https://test.libreelec.tv/13.0/Generic/Generic/ (scroll down for latest)
If nothing changed, put Kodi in debug mode, reboot, then play something and run "pastekodi" again.
Update to a current LE13 nightly image from https://test.libreelec.tv/13.0/Generic/Generic/ (scroll down for latest)
If nothing changed, put Kodi in debug mode, reboot, then play something and run "pastekodi" again.
I have no advice on brands for these kinds of things, there is too much variation. You can also read the Denon AVR thread, but "Caveat Emptor" applies ![]()
The Kodi release manager tagged the 21.3 release ![]()
The same release manager has then paused the push of release notes and wider rollout after noting a minor issue for a couple of the platforms that Kodi ships binaries for. That seems to be taking time; such is the nature of all-volunteer FOSS projects where folk have real-world commitments that need their attention too.
Until something changes, the tagged 21.3 release is still the tagged 21.3 release and Kodi still seems to play movies and tv shows. Go watch something instead of obsessing over release numbers.
There is no need for multiple threads on the same issue so I have merged the latest post into here.
Using the latest log we can see the following:
2025-11-11 19:38:15.112 T:998 info <general>: VideoPlayer::OpenFile: nfs://192.168.192.242/Multimedia/Mediatheken/Serien/Dept. Q/Staffel 1/01 - Folge 1.mp4
...
2025-11-11 20:00:19.722 T:998 debug <general>: HandleKey: play_pause (0xf0bd) pressed, window 12005, action is PlayPause
2025-11-11 20:00:19.762 T:30400 debug <general>: CDVDAudio::Pause - pausing audio stream
...
2025-11-11 20:03:10.152 T:998 debug <general>: HandleKey: play_pause (0xf0bd) pressed, window 10142, action is PlayPause
2025-11-11 20:03:10.153 T:30400 debug <general>: CDVDAudio::Resume - resume audio stream
...
2025-11-11 20:42:00.918 T:30398 debug <general>: CPtsTracker: detected pattern of length 1: 40000.00, frameduration: 40000.000000
2025-11-11 20:42:59.535 T:30398 warning <general>: OutputPicture - timeout waiting for buffer
2025-11-11 20:42:59.957 T:30398 debug <general>: CPtsTracker: pattern lost on diff 0.000000, number of losses 1
2025-11-11 20:43:05.535 T:30398 debug <general>: CPtsTracker: detected pattern of length 1: 40000.00, frameduration: 40000.000000
2025-11-11 20:43:38.703 T:1085 warning <general>: ActiveAE - large audio sync error: -1599.897181
2025-11-11 20:43:38.705 T:1073 debug <general>: CLibInputKeyboard::ProcessKey - using delay: 400ms repeat: 80ms
2025-11-11 20:43:39.063 T:31758 debug <general>: Thread Timer start, auto delete: false
2025-11-11 20:43:39.153 T:1085 warning <general>: ActiveAE - large audio sync error: -2256.463541
2025-11-11 20:43:39.153 T:1085 warning <general>: ActiveAE - large audio sync error: -2257.239806
2025-11-11 20:43:39.445 T:31758 debug <general>: Thread Timer 140212931868352 terminating
2025-11-11 20:43:39.867 T:1086 error <general>: CAESinkALSA - snd_pcm_writei(-32) Broken pipe - trying to recover
2025-11-11 20:43:40.246 T:1085 info <general>: Skipped 1 duplicate messages..
2025-11-11 20:43:40.246 T:1085 warning <general>: ActiveAE - large audio sync error: -3339.997892
2025-11-11 20:43:40.246 T:1085 debug <general>: ActiveAE::SyncStream - average error -1000.000000 above threshold of 100.000000
2025-11-11 20:43:40.306 T:1085 debug <general>: ActiveAE::SyncStream - average error -21.496599 below threshold of 30.000000
2025-11-11 20:43:40.306 T:1085 warning <general>: ActiveAE - large audio sync error: -2408.135241
2025-11-11 20:43:40.306 T:1085 warning <general>: ActiveAE - large audio sync error: -2408.656654
Display More
So playback starts at 7:38p, is paused at 8:00pm, resumed at 8:03pm, then the state tracker goes schizoid at 8:43pm. There is nothing in the log to indicate why, but the most logical explanation is the connection to the media source being interrupted.
Please run "pastekodi" or "journalctl | paste" and share the URL so we can see what the OS is doing around the same time.
Is there a way to run LibreELEC inside a docker container
No. You can virtualise an OS with a hypervisor. You can virtualise an app with a container. LE is an OS, not an app.
So you either install Docker on LE (which exists) and then add (and you support) the containers you need. Or you can run another OS that supports containers and run Kodi via a container (something probably exists). Or you run another OS with a hypervisor and run LE as a guest OS on that hypervisor. An OVA for vmware hypervisors exists for project staff to use for dev work and some users are known to run LE that way. Note that the OVA is unsupported; meaning that all other use of it must be self-supported.
Any idea what I can check to help you?
Push the uncompiled device-tree (dts) file that includes your modifications to a GitHub repo so I can see them. NB: You won't get any meaningful feedback from the systemd service because the setup script is blindly dependent on the compiled dtb. The content in the dtb file is either right and it works, or wrong and it doesn't.
The "pastekodi" command is probably failing due to the size of the log (limits on the paste server are generous, but there are limits) and the Kodi log is zero value because it's captured hours after boot, so it has rotated and useful info shown during initial startup is no longer present. It also looks like you copy/pasted from a terminal session as some text is truncated (not a major thing..).
The OS seems to have an issue with the iwlwifi card as this is throwing errors. Not sure it's too important but it adds to the log noise and might indirectly impact on other aspects of boot. Nothing else really stands out to me.
However, audio capabilities in Kodi are determined from EDID data on the HDMI connection at startup. If Kodi cannot see/find audio hardware either the kernel doesn't detect it, correctly or (more likely in this case) something is messing with EDID data.
I'll make an educated guess that the HDMI output spec from the NUC is not aligned to the HDMI spec of the input on the AVR, e.g. something like the NUC only supporting 4:2:0 and the AVR requiring 4:2:2. It reads a little like you picked "the best port" for input on the AVR but instead of ensuring best results this could be counter-productive and you might need to swap to another (lesser) input port or experiement with changes to the HDMI spec support of the port to make things work. I'm being a little vague about things here because different vendors name things differently. The important thing to understand is that HDMI is a collection of standards (interpreted by vendors) not 'a' standard.
I would also experiment with cables (only use HDMI 2.0 certified ones) and the second HDMI port on the NUC, and also external DP to HDMI adapters instead of the HDMI output sockets on the NUC. The reason being that most NUC like boxes omit proper HDMI transciever hardware to save $$ and instead uses an internal DP to HDMI adapter (aka LSPCON chip) which contains closed-source firmware doing magic and imposing unseen limitations on the display chain - they are often oriented towards output on monitors more than TV's. Make sure the BIOS/firmware of the NUC and if separate any LSPCON firmware updates are applied as they can/do contain bugs. The advantage of external DP > HDMI adapters is that they aren't soldered to the motherboard inside the box so you can order a bunch of different ones and experiment until you find one that works. NB: There is also a long-running 'Denon AVR' thread elsewhere in the forums that you can read, but IIRC the main conclusion of that thread is people ditching the internal HDMI ports for external DP > HDMI adapters. The tertiary challenge is that different brands of adapters are available in different parts of the world, and even if the same brand is available there's no guarantee the LSPCON chip and firmware inside the latest batch of adapters is the same as the chip and firmware that someone tested a year ago and worked great. LSPCON chips in NUC boxes has been "the gift that keeps on giving" for HDMI support issues since they first appeared 6-8 years ago.
Note to self .. I should scrape this text ^ into a wiki article, it's not the first time I had to write it all out long-hand ![]()
From the descriptions it sounds like a kernel issue, but without some form of log evidence we really have nothing to research. If you remove "quiet" from kernel boot params in syslinux.cfg it will dump the system log onto the screen during boot. Record the screen as a slow-motion movie and as long as your hands are steady it's normally possible to play the resulting movie back and read the text to spot error messages. Upload load the movie to a sharing site somewhere and we can see it too.
NB: If LE 12.0 works on the boxes (but not LE 12.2) stick on the earlier release until kodi-headless has a K22 release available. The diff between Kodi versions isn't large so it's not a 'must have' update.
Enable SSH and see if you can access the device to run “pastekodi” and share the URL or perhaps just “dmesg > dmesg.log” or “journalctl > system.log” to dump info to disk so that post-downgrade you can do “cat *.log | paste” and share URLs. In short, we need to see some logs to have any idea what the issue might be.
mglae busybox unzip is missing unicode support so it's more than just the locale.
However I feel a utf-8 unzip would probably help others extracting downloads etc.
I don't recall this issue coming up before despite umlaut and DVB loving Germans being our largest demographic, and there are multiple workarounds (7z, zipfile, etc.) so I don't see much need to replace busybox unzip with the full-fat version.
If LE added everything that would 'probably help' it would be a 1.2GB distro download like Ubuntu ![]()
Is it possible to change the quirks being selected without rebuilding LibreElec?
The challenge is that there are so many quirks that could be used (and most with little guidance on their use) that we have no clue what might need to be poked; or even that some missing quirk is the solution.
This is a super-simple python script to unpack the NPVR.zip file:
#!/usr/bin/env python3
import zipfile
with zipfile.ZipFile('NPVR.zip', 'r') as z:
z.extractall('/storage/.kodi/addons/pvr.nextpvr/files/etc')
Unlike busybox unzip, python 'zipfile' will preserve the filenames, e.g. after unpacking:
ROCK5B:~ # ls -l npvr/data/tuning/* | grep Austria
-rw-r--r-- 1 root root 1194 Nov 11 16:13 Austria - All Regions.ini
-rw-r--r-- 1 root root 1016 Nov 11 16:13 Austria - Alle Regionen.ini
-rw-r--r-- 1 root root 140 Nov 11 16:13 Austria - Burgenland.ini
-rw-r--r-- 1 root root 138 Nov 11 16:13 Austria - Kärnten.ini
-rw-r--r-- 1 root root 219 Nov 11 16:13 Austria - Niederösterreich.ini
-rw-r--r-- 1 root root 163 Nov 11 16:13 Austria - Oberösterreich.ini
-rw-r--r-- 1 root root 120 Nov 11 16:13 Austria - Salzburg.ini
-rw-r--r-- 1 root root 158 Nov 11 16:13 Austria - Steiermark.ini
-rw-r--r-- 1 root root 171 Nov 11 16:13 Austria - Tirol.ini
-rw-r--r-- 1 root root 122 Nov 11 16:13 Austria - Vorarlberg.ini
-rw-r--r-- 1 root root 80 Nov 11 16:13 Austria - Wien.ini
Display More
Create /storage/.restore and place the backup file there and reboot. On restart it will be detected, the dirs that will be overwritten will be deleted (/storage/.kodi, /storage/.config, and /storage/.cache) and then the backup is decompressed to /
You can also use the restore function in the GUI which will copy the file from wherever you have it to /storage/.restore then force a reboot to start the process.
Or use tar commands to extract files and do other things with the backup file. It's just a standard tar archive.
Windows does not understand and cannot 'see' Linux EXT4 partitions like the second/storage partition that cannot be mounted so it will not find issues with them or solve anything.
Use GParted for scan and repair. This tool can leave bad blocks out during formatting.
If the device has failing cells it's only a matter of time (and usually not much time) before more cells or the entire card fails.
If it was just corrupted then reformat with any tool will fix. No need to jump through extra hoops with GParted.
Is the SD card with the problems completely broken, or will formatting it be enough to get it working again?
Impossible to tell .. but costs $0.00 to experiment.