I'm really sorry for my compile noobness, but how do I check?
"git show <hash>" should output the patch content if the upstream kernel hashes have been merged correctly into the downstream Raspberry Pi kernel source that we use with RPi images. If they haven't, that will error and you'll have to search (grep) the commit log to find the commit message and confirm the patch is present.
Direct firmware load for brcm/brcmfmac43456-sdio.radxa,rockpi4b.bin failed with error -2
Direct firmware load for brcm/brcmfmac43456-sdio.clm_blob failed with error -2^ Those are harmless messages; the driver looks for board-specific firmware/nvram files before falling back to generic files, and it's rare to see any devices have clm_blob (board-specific performance tuning) files available.
Your board will be using generic files, so there's two things to try:
a) Update to a current LE12 nightly so you're using a recent kernel that may have driver fixes.
b) Some boards need specific firmware/nvram config as generic files cause problems. So I'd have a look in Radxa GitHub repos (or Armbian) to see what they ship with that board. If you put the files in /storage/.config/firmware/brcm/ with the filename brcmfmac43456-sdio.radxa,rockpi4b.bin (firmware) and brcmfmac43456-sdio.radxa,rockpi4b.txt (nvram) and reboot, they will be used instead of the generic files. If that fixes the problem point me to links and we can add them to our images.
Otherwise it's not something I've seen before with Broadcom modules. It does happen with cheap Realtek USB dongles where the manufacturer was too lazy to get unique OID's for their devices or programmed everything with 00:00:00:00:00:00.
Congrats 
The ideal thing would be for the i2c/i2s bits to be obtained from device-tree allowing a common driver module to be upsteamed to the mainline kernel with minor device-tree changes (applied through an overlay) providing the runtime differentiation between RPi and RK (or any other compatible) SoC type.
Any ideas?
Remove any config.txt changes and the edid bits from cmdline.txt and update to an LE12 nightly, then test again. There are specific fixes for display issues and LE10 is no longer maintained.
Is this patch in the kernel source? https://patchwork.kernel.org/project/linux-…foundation.org/
The DVB module drivers are disabled in all LibreELEC images because the (multiple) driver sources we used to include were never updated within months of a major kernel bump and over time became more and more unreliable to use/include. We now support only DVB cards with upstream kernel support.
Map the "AudioDelayPlus" and "AudioDelayMinus" actions to buttons on the remote keymap and it should be possible.
There's no concept of sideloading in LE. You can either self-build an LE image with the Python bump reverted, or rework the SSL bits around newer Python, or route requests through some kind of reverse proxy so that LE > Proxy uses modern TLS and Proxy > Site uses older ciphers.
I'd guess that auto-discovery uses UDP broadcast so anything on the same switch or subnet can receive that traffic and show the server(s) available. However Kore needs to make a direct TCP connection to Kodi for control, so if e.g. a VPN connection is active and configured to "route all traffic" (noting the problem in your previous post) that connection will be routed down the tunnel and will fail. If that's not the issue, you need to share IP/subnet and routing table info for the Phone and the HTPC.
HDMI splitters have the advantage of being somewhat universal so if/when you update the RPi3B to something newer (which likely still has a single HDMI output) there's no change to the arrangement whether it's RPi or some other SoC/hardware. That said, HAT devices can be "recycled" with e.g. RPi5 as the GPIO pinout on RPi5 remains the same as RPi3 so if you go that route the update path is limited but you can still reuse. The main question to figure out for yourself is how much or little you want to spend?
Using an overlay is probably the "more technically correct" way to do things but I wouldn't worry about that until you have a working set of changes. Patching the kernel source will have an easier dev workflow as you figure those changes out.
It's been a while since I used a VIM3L for anything but the general state of the AMLGX image on SM1 boards should be the same as for G12A/B and I use an N2 (G12B) as part of my test regimen. If you read current LE11 release notes there's a long explanation of the general state of Amlogic things (LE12 doesn't change much). If you need 10-bit HEVC media (or 4K) then CE will be more feature complete, but if your media collection is more simple (mostly H264 and 8-bit HEVC, some VP9) then AMLGX can be an option too, and I see a slow but steady increase in users on "newer" Amlogic boards running AMLGX these days.
Official LE12 nightlies are a little behind my test branch (will be updated once some visiting relatives go home and I have some time to spend on it). Until then https://chewitt.libreelec.tv/testing/LibreE…as-vim3l.img.gz is available if you want to experiment.
I made a mistake when updating the image last time so the firmware file wasn't included. If you update to the same file again, this time it has the firmware inside. Then share a log again.
Kodi feature requests should be made to Kodi developers via the Kodi forum.
Put the .tar file in /storage/.update and reboot to update.
I have a hunch anonymous auth just means "accept whatever is given" so set user = kodi, pass = kodi and see what happens.
I have a hunch the AMLGX image is missing the firmware for the card. Please update to this (LE12) image and test again:
https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.aarch64-11.80.0.tar
