Posts by chewitt

I've pushed updated images with some initial WIP support for VP9 hardware decode on RK3588 (limited to Profile 0 = 1080p). The codec driver has literally been found hiding in plain sight on GitHub earlier today; the work of a Computer Science undergraduate who has been working on Android images for recent RK boards. I am yet to chat with the author about his plans, but there are code and reddit comments about wanting to add 4K support and upstream which sound positive.

NB: If the driver matures a little more it should be reasonably simple to extend support to RK3566 and RK3568, but RK3576 uses a newer IP block that is "similar but different" enough to need a separate driver.

2025-12-15 07:51:37.048 T:1817     info <general>: VAAPI::SupportsFilter vaDeriveImage not supported by driver - ffmpeg postprocessing and CPU-copy rendering will not be available
2025-12-15 07:51:37.048 T:1817    error <general>: VAAPI/vpp vaCreateConfig error: the requested VAProfile is not supported (12)

Your log is not a debug log (which would be useful to see) but this ^ appears to flag an issue with VAAPI, which is kind of 'new' to nVidia hardware since https://github.com/LibreELEC/LibreELEC.tv/pull/10669 which bumped the mesa version to v25.3.0 which notably dropped VDPAU support and switched over to VAAPI. I'd hazard a guess the VDPAU > VAAPI change might require Kodi settings changes as VDPAU and VAAPI have slightly different featuresets.

The other thing I note is that Kodi only detects the BT audio device, which is probably the known alsa regression fixed in https://github.com/LibreELEC/LibreELEC.tv/pull/10785. The regression effectively causes Kodi to have a broken/invalid audio config and this may also cause Kodi to behave badly; although I would expect to see alsa errors in logs not VAAPI errors. The alsa regression has been fixed (with some backported patches) in nightlies from the last 24-48h.

NB: Problems have nothing to do with the waipu add-on, it just happens to play media in a format that requires decoding and thus the VAAPI issue surfaces. The HomeAssistant addon is also nothing to do with LE so you need to direct any questions about it to the Kodi forum or the HA forum (wherever the add-on is normally supported). It's probably a Python issue that might be provoked by LE running a newer Python3 version than the authors have tested with, but that's still a distro packaging issue for the add-on authors to solve not LE maintainers.

Since it's a binary add-on it needs to be compiled and published by the distro that provides Kodi, hence it's in our repo. However the correct place to report an issue is the add-on support thread in the Kodi forum. Or if you are capable of providing an insightful issue report with a decent amount of technical detail, the GitHub issue list for the add-on.

NB: You should consider that these add-ons are niche and likely haven't been touched in a while or are another unmaintained bit of the Kodi codebase (about 70% of Kodi features have no assigned maintainer). Whinging about how things do or don't work is rarely the best way of distracting a Team Kodi developer (an unpaid volunteer working in their spare time) to your cause.

I've pushed updated images for RK356X, RK3576, RK3588 to my test share. These are now using Linux 6.18.1, and the v4l2_request patches currently being upstreamed to FFmpeg not the patches LE has used in recent years. FFMpeg devs have requested a few things to be moved around in code to align with their standards and this has surfaced an issue where Kodi shows visual glitches in video when OSD objects like vol up/down, navigation bars, etc. are overlaid on the screen. We have already figured out roughly what the underlying issue is, but it might take a while to come up with a proper fix. On the upside, the latest patches add FFMpeg support for the hantro AV1 hardware decode IP block on RK3588.

Two steps forwards, one step backwards

Dec 14 07:45:23.313958 kernel: pci 0001:01:00.0: BAR 4 [io  size 0x0020]: can't assign; no space
Dec 14 07:45:23.314046 kernel: pci 0001:01:00.0: BAR 4 [io  size 0x0020]: failed to assign
Dec 14 07:45:23.314274 kernel: pci 0001:01:00.0: BAR 0 [io  size 0x0008]: can't assign; no space
Dec 14 07:45:23.314378 kernel: pci 0001:01:00.0: BAR 0 [io  size 0x0008]: failed to assign
Dec 14 07:45:23.314470 kernel: pci 0001:01:00.0: BAR 2 [io  size 0x0008]: can't assign; no space
Dec 14 07:45:23.314537 kernel: pci 0001:01:00.0: BAR 2 [io  size 0x0008]: failed to assign
Dec 14 07:45:23.314615 kernel: pci 0001:01:00.0: BAR 1 [io  size 0x0004]: can't assign; no space
Dec 14 07:45:23.314708 kernel: pci 0001:01:00.0: BAR 1 [io  size 0x0004]: failed to assign
Dec 14 07:45:23.314776 kernel: pci 0001:01:00.0: BAR 3 [io  size 0x0004]: can't assign; no space
Dec 14 07:45:23.314863 kernel: pci 0001:01:00.0: BAR 3 [io  size 0x0004]: failed to assign

The only thing that stands out(ish) to me is this ^ but I'm no expert on HAT boards or PCI things.

Shortly after those messsages is Some PCI device resources are unassigned, try booting with pci=realloc so I would see if adding pci=realloc to kernel boot params in cmdline.txt does anything?

Just create a new thread owned by you. I'm not sure why the post wasn't editable.

You can use meson-gxl-s905l-p271.dtb to boot the AMLGX image: https://wiki.libreelec.tv/hardware/amlogic

N2PLUS:~ # mv box.dtb box.dump
N2PLUS:~ # dd if=box.dump of=box.dtb bs=1 skip=2048
N2PLUS:~ # dtc -I dtb -O dts -o box.dts box.dtb

After renaming the file, carving out the dtb, then decompiling the dtb: https://paste.libreelec.tv/amazing-oyster.log

This shows the box is an S905L (p271) board, which is a cost-reduced version of S905W for the Chinese market. It omits VP9 support and uses a Mali 450-MP2 GPU instead of the Mali 450-MP3 used with S905W/X boards. You MUST boot using the p271 dtb file. If you boot with any dtb that describes a Mali 450-MP3 the kernel hard-faults and boot fails.

Computeraar If the problem is "Kodi won't start" a textmode boot log isn't going to show anything useful because Kodi isn't being started. Create /storage/.kodi/userdata/advancedsettings.xml with this content to put Kodi in debug mode:

<?xml version="1.0" encoding="utf-8" ?>
<advancedsettings version="1.0">
  <loglevel hide="false">1</loglevel>
</advancedsettings>

• Then touch /storage/.config/safemode.disable to ensure that safe.mode doesn't kick in
• Then tail -F /storage/.kodi/temp/kodi.log > log_dump with capital F and tail will wait/watch for the file appearing
• Then systemctl start kodi and allow it to fail a couple of times before stopping the service
• Then cat log_dump | paste and share the URL
• Then systemctl | paste and share the URL

If we're lucky the logs might have some clues on what the problem is ..

FATAL ERROR: Blob has incorrect magic number

NB: the dump/blob shared is not a dtb ^ (cannot be decompiled) so you'll need to use a tool like binwalk to figure out the offset to where the dtb data is located in the file, and then carve it out using dd.

NB: with the second one, leave video=HDMI-A-1:1280x720M@60D in kernel boot params as the board is going to see a monitor that can do at least 1080p output and Kodi will want to run at 1080p.

Quote from Protx

Armbian have a dts file/patch for their "edge" 6.18 kernel

From the amount of /delete-node/ and /*commented*/ items in the file I'd guess it either forward-ports a device-tree file that was originally written for the vendor kernel or is a hand-rolled attempt from an inexperienced developer. It probably works(ish) but six months has elapsed since it was created so (as normal for Armbian patches) the author clearly has no intention of trying to submit support for the board upstream, and that's probably because this dts is too much of a hatchet job to be accepted.

https://github.com/armbian/build/pull/8348 <= The "VPU (Unable to test due to lack of VAAPI support)" comment is amusing

The Armbian PR also confirms the board needs an out-of-tree Ethernet driver to work. For both board and Ethernet support I'll be happy to cherry-pick patches submitted to kernel mailing lists, or items from known kernel contributors (who are trusted to follow-through on upstreaming them) but that's my minimum threshold.

NB: The LE13 nightly image will have an audio issue (will be fixed over the next few days) but that doesn't affect iwlwifi ..

The log contains a prominent kernel splat from the iwlwifi driver and Google (re)searching on that throws up a large number of bug reports from a large number of distros over a long period of time. I didn't find anyone really getting to the bottom of things but the recurring theme is "PCI issues" and some users report success when disabling some features of the kernel driver.

I'd suggest updating to the latest BIOS/firmware for the board then retesting with an LE13 nightly dating from tomorrow (as this will have the Linux 6.18 kernel update merged earlier today).

If that doesn't magically solve anything, something like this might be needed https://www.edu4rdshl.dev/posts/fixing-i…ashes-on-linux/

Two things to try:

a) Run "getedid delete" then add video=HDMI-A-1:1280x720M@60D to kernel boot params and use the HDMI port nearest to the PSU connector. This forces the initial kernel DRM state of the connector to 720p output which sometimes resolves handshaking issues.

b) Run "getedid delete" (to remove the possibly bad van EDID) and connect to the working monitor and run "getedid create" then power up with it connected to the van and see if anything shows up on the display?

Quote from ghusto

Libreelec is not an embedded system, and "we" can take advantage of that fact

I've quoted the "we" for emphasis ^

Kodi devs made a serious proof-of-concept for a Kodi-internal browser 3-4 years ago. This proved that it was a non-trivial feature to bring to Kodi. The prototyping showed a mountain of platform-specific code was needed (Kodi supports 6+ platforms) and it would also need frequent updates to manage the inherent security issues of a browser; the underlying browser engine (Chromium) is in a state of constant change for the same reason. The team concluded that adding a browser is technically possible, and we all see the value of having one, particularly to ease the challenge of accessing streaming platforms. However the overall level of effort required to implement and then maintain an in-Kodi browser doesn't align with how Kodi is [under]staffed since forever or the anarchic way the project operates itself.

Quote from ghusto

I feel a lot of hostility towards actual users when they have reasonable requests like this.

I'm normally aiming for sarcasm more than hostility, but "we" get bored of new users showing up and expecting us to treat their reasonable suggestion differently to all the previous times the same reasonable suggestion was already reasonably answered.

Please update to an LE13 'Generic' (not Generic-Legacy) nightly and see if that works better?