Posts by chewitt

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.

Quote from dale

With latest build for rk3566, I got high cpu/gpu temperature (71C) and sometimes crash. Is it expected?

High temps aren't expected unless doing something CPU intensive, e.g. software decoding. NB: CPU temp is reported, GPU is faked in the Kodi GUI (re)using CPU data. Most boards also benefit from heatsinks and cases that conduct heat. The 71ºC temp is higher than desirable but most boards can run a lot hotter than we're comfortable with so it's probably short of problem levels.

Crashes (not heat related) are perhaps more expected given the current experimental state of images with 160+ patches. There are known issues with DRM buffer sizes that will probably show up with HEVC media and spam the system log with IOMMU page-fault reports. If those start showing the system ends up in a state that will ultimately need a reboot to recover from.

NB: Put kodi in debug mode and then use "pastekodi" to share log URL's post-crash. Guessing at issues isn't our strength

Note that in LE13 the timezone setting is removed from Kodi and is now configured in the LE settings add-on.

Quote from tequomo

Please look at the sent log. Maybe, after all, it will be possible to find the reason?

You will receive no support in this forum while banned add-ons are installed.

Official:Forum rules/Banned add-ons - Official Kodi Wiki

Quote from Fartmaster5000

Is there a plan in the future to support the latest versions of Kodi (21.3)?

No plans. Kodi removed support for amcodec in 2018 to focus on non-proprietary decoding methods and community efforts to hack support back in to current Kodi versions are now focussed on newer Amlogic kernels that do not support older Amlogic hardware.

ChatGPT analysed the splats and suggested the change, but GoogleAI claims the CPU is 'Sea Islands' and not 'Southern Islands' and according to https://wiki.archlinux.org/title/AMDGPU this needs a different config. This would explain why it doesn't appear to have switched drivers.

So see if changing to radeon.cik_support=0 amdgpu.cik_support=1 makes a difference? - I would also disable SMB component debug logging as this only adds to system load. Also experiment with 'start/stop' option for adjust-refresh, as this is a little less aggressive at syncing. This article is not just for 4K/HDR and has suggestions https://wiki.libreelec.tv/configuration/4k-hdr

It's possible there's some fallout from this change: https://github.com/LibreELEC/Libr…dad6c4cf3d49647

Can you put Kodi in debug mode and attempt to change the data and then "pastekodi" and share the log (URL) so we can see if there's an obvious error message (might be, might not be).