Posts by chewitt

In Kodi debug logs there is normally a section after debug <general>: CDRMAtomic::InitDrm - initialized atomic DRM and before the debug <general>: CWinSystemGbm::InitWindowSystem - initialized DRM line that displays info on the EDID data presented on the active HDMI connector Kodi is using. This data is missing from the log. However, in addition to colourspace data, the EDID data contains info on audio capabilities and in the audio section of the log names of the TV and AVR are visible so this appears to be read from the HDMI connctor okay. Most odd..

popcornmix there's been a couple of similar reports in LE12.2, any ideas?

ConnMan will show show a valid service as long as the config file is complete; doesn't mean the config is correct. The main item that you might need to figure out is the host IP of the server. ConnMan cannot currently resolve an FQDN to an IP so you need to replace any hostnames in the Mullvad config with an valid IP. Most VPN providers use hostnames because they are frequently changing the IP's that their nodes resolve to, and most hostnames resolve to multiple A records.

Extracting the dtb from an Android image is guaranteed to result in boot failure. Even if you rename dtb.img and configure uEnv.ini to use it correctly, the Android vendor kernel you pulled the dtb from has no code in-common with the mainline kernels that LE uses in the AMLGX image and kernel and dtb need to be version aligned.

If the box has an S905W chip the only device-tree files that might work are meson-gxl-s905w-p281.dtb or the similar Tanix TX3 mini device. It's a cost-engineered box with a CPU that runs/clocks slower than other GXL designs so p212 or similar may attempt to run the CPU faster than it can boot or reliably operate at. I would only use LE12.2 or perhaps an LE13 nightly image to attempt boot. LE9 images predate the existance of S905W (so don't support the chipset) and we no longer support those images.

If the device isn't booting to the LE splash screen or Kodi the only way for us to provide any support is to see the early boot log. This is obtained by connecting a USB serial UART cable to TX/RX/GND pins on the board; assuming they exist, and if not they need to be soldered in-place. The log will show what Amlogic u-boot attempts (or not). In the absence of the log we are blind to the issue and it's not worth the time/effort to guess at things.

NB: read https://wiki.libreelec.tv/hardware/amlogic to understand a little more about LE differences

Most providers simply generate all the keys needed for a client node to be configured to work with their server. This is technically less secure (as they generated and thus could know/store the private key of the remote device) but that doesn't seem to bother most users who only care about a connection that hides their presumably dodgy activity. I've never seen the Mullvad device generator tool but if they allow you to provide a public key and optional preshared key, which they store to authenticate your client node, this is more secure, but not really more complicated; the tool will still generate a conf with the content you require.

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.