Posts by chewitt

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).

Quote from Boulliebeest

Any way to force LibreElec to use db version 139?

You cannot force, but you can downgrade to an older nightly that still uses the same DB version. Note that you will then need to drop the newer tables from the database else when you later bump to a newer version the tables already exist and the migration process will not be (re)triggered.

Quote from Yasai-san

I made PR as https://github.com/LibreELEC/LibreELEC.tv/pull/10960 .. please close this PR.

Thanks, I'll close when Radxa respond to the upstream plans question in https://github.com/radxa-pkg/aic8800/issues/71

radeon.si_support=0 amdgpu.si_support=1

Some ChatGPT analysis of the kernel splats in the log suggests Kodi triggers a GPU driver bug. It also claims there are long-running issues with the (newer) radeon driver on old(er) hardware. It does also suggest disabling HW decoding to see if that code-patch is involved. And from your comment, it appears it is. I have no real knowledge of AMD hardware but it suggests seeing if the older amdgpu driver works better than radeon? .. which is achieved by adding the above ^ to the kernel boot params in the EFI boot config (as you are EFI booting and not using Syslinux). You can edit that from SSH by doing mount -o remount,rw /flash and then editing the file, then rebooting. If it doesn't work out things might crash or not display but you should still be able to SSH back in and revert the change made.

LE10 to LE12.x requires you to navigate the Python3 change in Kodi so deleting all (Python2) add-ons before update mitigates issues with them crashing and causing problems on post-update restart before Kodi has been able to download newer (Python3) versions. Add-on settings remain intact so normally all you need to do is reinstall add-ons from repos again. The Estuary Mod v2 skin seems to be available (under a new maintainer) https://forum.kodi.tv/showthread.php?tid=366400. The rest of the OS should update fine and you do not have an nVidia GPU so there is no need to run the Generic-Legacy image.

Quote from Yasai-san

I don't create Pull requests for AIC8800 driver because I agree with chewitt and LibreELEC perspective.

Yasai-san Just create a pull-request with "This PR is being submitted so information on how to add the AIC8800 driver package into a self-built image is more easily found. I support the project's wish to not add downstream drivers that have no visibility of being upstreamed and do not expect this to be merged" .. so we look less authoritarian when we close it without merging

It is not impossible to create/build mainline u-boot for eMMC install on Android TV box hardware, but this requires the original BL2 (and BL301) sources for the specific hardware (tweaked by the manufacturer for the out-of-spec low-bin RAM chips used in specific batches of boxes) which you don't have. It is also not impossible to reverse engineer boot firmware to extract the pre-compiled bits, but this requires the original Android ROM which you don't have. That task also requires tools/skills most users lack, and a level of repetitive "puling your teeth out" time and effort of that project staff have learned to avoid, and this is why none of the distros that you mentioned are interested in supporting eMMC install on Android boxes; except in a few rare cases where the original sources are available and the outcome is reliable.

You might have greater success in sourceing ROM images or find a more willing audience in Android supporting forums.

The Allwinner image supports overlays so you can probably just drop the existing dtbo file onto the SD card and modify the extlinux.conf to use it; LE and Armbian should be similar in how that’s done as they both use mainline u-boot.

Or you need to compile an LE image with a kernel patch to add the overlay so it will be compiled and added to the image. Or you submit the patch to our GitHub repository so it’s merged and added to the image; although we mostly refuse patches that are not also submitted to kernel mailing lists (we want to know the patch is good and will be dropped in the future when the fix is upstream).

Quote from dtech

you just need to run this command again because someone has already received the same link before.

Correct.

Running the Kodi GUI at 4K resolutions (as per the other issue thread) probably doesn't help the GUI responsiveness. I wouldn't be suprised if running things at 1080p improves the remote situation?