Posts by chewitt

If there was a general problem with DHCP on WiFi connections with LE13 nightlies there'd be a ton of posts on the topic, and there aren't. So whatever the issue is, i'm confident it's local to your environment.

ConnMan debug logs are verbose and somewhat human-readable, but if you have a poor signal the inherent 'noise' that will add to the logs will make it challenging to spot any real issues. Poor signal is not the cause of the invalid-key issue, but as the issue is likely to be an unhandled radio/wireless error condition (the patch on the list is addressing that) poor signal correlates to the problem.

Quote from tandpijn

Can you confirm if it is worth trying to add sunshine DIY?

It doesn't matter whether you wait for core devs to implement something that can't work or DIY it yourself.

The release notes for LE10/11/12 have longer comments and warnings on the general state of Amlogic support, but in-short: H264 works well but the HEVC code was never finished and there has been nobody actively working on that codec since 2020 so there are no expectations of improvements to that driver. The config described here https://wiki.libreelec.tv/configuration/4k-hdr will give the best (or least-worst) results but some issues with HEVC seeking are known and expected. The S905X chip in the box is a typical ARM SoC with a weak CPU so software decode isn't a viable option for anything larger than SD media.

Amlogic are finally upstreaming hardware decode drivers (with plans to rework the entire DRM layer) which is long-overdue and great to see. We are working with them behind the scenes to help get changes tested and merged in the kernel, but their initial focus is H264/8-bit/1080p on S4 hardware (S905Y4/S905W2/S805X2). That effort is making slow progress due to kernel standards being rather higher than Amlogic's in-house ones, so it's going to be a while before HEVC/4K/HDR support exists and then gets backfilled to older hardware.

You might want to look at the vendor kernel image that dtech maintains. This will be more functional than AMLGX and contains a few updates to keep things ticking over, albeit add-ons and such are starting to die off under that era/version of Kodi.

Quote from update.freak

Is this still the case or what is here the current status?

It is still and will always be the case as LE runs a zero-copy display pipeline and this means frame capture is not possible. You need to use an external hardware grabber, then install either Hyperion (we use the original still, not NG) or HyperHDR to use it.

I'd be interested to see if this patch resolves the invalid-key issue: https://patchwork.kernel.org/project/connma…[email protected]/ .. as the title of the patch sounds promising but the author of the patch has provided zero info on the issue being fixed so that might be a coincidence. If you want to self-build an image to test, this is the change required: https://github.com/chewitt/LibreE…d93d6047769fb94. If you have an RPi5 board this LE13 image contains the patch: https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz. NB: LE13 nightlies will have newer kernels and latest/correct drivers for the wireless chipset that you're using so I wouldn't bother triaging with LE12/12.2 images.

Quote from tandpijn

I imagine running a VM / Container with KODI on a VM server and being able to access it from any low-end device or SmartTV running Apollo/Moonlight.

This can probably be done with a conventional Linux distro, but not LibreELEC, as we use a zero-copy display pipeline. This means media is decoded from file/stream and each frame is stored in RAM using a (buffer) format suitable for rendering/output; so each stage in the display pipeline (Kodi, ffmpeg, DRM compositing, etc.) simply passes a pointer to the buffer containing the data instead of copying the data (hence zero-copy). The side-effect of this is that there is no opportunity to 'grab' the frame (as it's a pointer to data, not actual data) for display, which is how everything from VNC to fancier video streaming server capabilities obtain the frames to stream. This is the status-quo for 'Generic' (using GBM) and all ARM SoC hardware that LE supports. Only the Generic-Legacy image (using Xorg) is different, but that image is likely to be EOL at some point in the not-distant future so wouldn't be worth the time/effort of integrating around. Running LE in a VM is possible but then responsibility for streaming frames passes to the host OS and no changes are needed in the LE guest OS. NB: LE is quite intentionally a 'dumb-client' distro and this is our niche in the Linux/Kodi ecosystem. There's no real interest from project staff to diverge from that.

Quote from 2469

Can i still use it in the future?

One long-term challenge is that the latest nVidia cards are moving to an open-source (in-kernel) driver and GBM/Wayland, while more recent cards can also use GBM/Wayland but still need the vendor driver (cannot be packaged alongside the in-kernel driver) and older cards (like yours) still need the vendor driver and Xorg. GBM/Wayland is 'modern' which is nice, but Wayland does not support the userspace controlled refresh-rate mode switch that we use with AMD/Intel and ARM SoC hardware to give the best media playback experience so it's bit of a "one step forwards, one step backwards" improvement. To further complicate things, mesa has recently dropped VDPAU support and Kodi does not support NVDEC. Right now 'PlanB' would be to swap to a general purpose distro where you can install the right combination of drivers, but at some point updates will break support.

So it might be worth experimenting with the onboard Intel graphics (and nVidia card disabled). I'm not finding much info on the GPU for that MSI motherboard but it will be Intel and supports up-to HDMI 1.4, so while it would suck for games on Windows when compared to the nVidia card, its media hardware decode capabilities are probably similar and "good enough" for Kodi.

It would be better done in Kodi so that the feature is available to all Kodi platforms.

Just name the script /storage/autostart.sh and it will be run on each boot. No need to faff around with remotes.

USB drives that can be auto-mounted will be found under /var/media/XXXX where the XXXX name is either the disk label (if one has been set) or the UUID for the device. LE defaults to using the in-kernel NTFS3 driver for NTFS drives. It's also possible to install the 'fuse' based NTFS-3G driver add-on from the LE add-on repo. This will disable the in-kernel driver and use NTFS-3G instead. Some users have issues with NTFS3 and need to switch. You might also need to connect the drive to a Windows host to run chkdsk.exe and clear filsystem 'dirty' flags as Linux is currently missing the tools to do that itself.

Nice talk on Rockchip mainline status from Collabora at FOSDEM last weekend: https://fosdem.org/2026/schedule/…nline-rockchip/ .. LE is some way ahead with our crazy sized patchset, which will hopefully slim down over the next couple of kernel cycles.

Feb 03 21:04:00.551323 Wyse kodi.sh[1216]: Crash report available at /storage/.kodi/temp/kodi_crashlog_20260203210358.log

There's interesting stuff at the top of the crashlog ^ (the call stack and traces).

However, I found https://github.com/xbmc/xbmc/pull/27119 and some linked issues in the Kodi repo (https://github.com/xbmc/xbmc/issues/26915 and https://github.com/xbmc/xbmc/issues/27116) so next thing to do is update to a current LE13 nightly and retest. If you want to retain the option of downgrading do cp -R /storage/.kodi /storage/.kodi-12.2 first as while LE makes the process of rolling the OS back simple, Kodi addons/userdata don't support being downgraded.

Quote from Wuk-jvi

What would be next step to get fixed in LibreELEC?

Share the technical details of changes so we can see/understand them, ideally via commits to a GitHub repo, and if you've added binaries; a link to the upstream original source location. Then we can consider how best to implement or pick changes from what you've done to official images, or not. Changes need to work for all devices so binaries that only work on your board will be not possible for main images .. but right now we don't know what's involved, so no commitment.

The normal approach for dealing with Realtek chips with power issues is disabling power management via modprobe.d options

Happy to do a backport to an LE12 nightly (as we have no plans for more releases) if you can tell us the specific patch that contains the fix. Otherwise there's no plan to spend effort on figuring that out when updating to a current LE13 nightly fixes the issue.

The current version of PM4K in the 'Don't Panic' repo is not compatible with newer Python versions/libs. The workaround is to use the latest add-on source from https://github.com/pannal/plex-for-kodi/tree/develop_kodi21 as this contains fixes (and more). You need to download the source files from GitHub as a zip file, then unzip and rename the extracted folder to "script.plexmod" before re-zip'ing the folder. The zip file is then in a format that will install to Kodi (with install-from-zip allowed). If you only download the source and rename the original zip file the install to Kodi will fail.

dale The kernel runs out of memory (OOM) and oomkiller stops kodi.bin to avoid resource starvation. I've not see anything similar, but the board samples I use are all 2GB minimum (most are 4GB/8GB) so I'm not going to see OOM conditions.

CmaTotal:         524288 kB
CmaFree:          515660 kB

Splat analysis from AI tools points out the kernel has 512MB CMA allocated, which might be too much for your 1GB board. This is set during kernel compile through the kernel defconfig https://github.com/chewitt/LibreE…ch64.conf#L8038 but it can be overriden with a kernel boot param in extlinux.conf, so you can add cma=256m and see if that prevents the crashes?

Quote from f1gogata

HDMI Audio Passthrough not working .. Any ideas what can do to fix it?

You can write/author HDMI pass-through support, upstream it to the kernel, and then it will work.

I dropped the experimental patches from the image in my test share some time ago as the patch series no longer applies to current ConnMan sources (needs a rebase) and further work on it seems to have stalled in code review. The latter is probably due to known changes at Intel that ended support for a bunch of FOSS projects; the maintainer/release manager for ConnMan (and IWD) are the same Intel staffer. I'll ping the series creator to see what his plans are, but no promises.