Posts by chewitt

Quote from Roomen

How do I enable drivers in the kernel configuration?

Edit and save the file.

NB: I don't want to be rude, but if you need this level of Linux skills spoon-feeding, our complex embedded-style packaging means we are not the distribution you are looking for. Something like Ubuntu will be much easier for a beginner.

Quote from jim_p

Is there a chance to add b43? It may work better than debian's b43

It was already evaluated and found to be as rubbish as the last time we looked; nothing improved in more than a decade. Except for the occasional 'treewide' change to fix or mod something it's received no maintenance in years and is abandoned. I'm genuinely surprised that it hasn't been dropped from the kernel in a dead-code cleanup.

There are lots of LE13 nightlies on the server. I'm less sure about older Tvheadend versions but there's probably a few.

If you can roll back and experiment to prove software caused the change we can investigate. If there's no correlation, it's something else, i.e. environmental.

The kernel defconfig is located at projects/Generic/linux/linux.x86_64.conf not under the Linux package folder.

Quote from hcliec001

Using mpv-libplacebo as the playback backbone of Kodi would be a gamechanger imho

Kodi on Linux is a big fancy (and deeply integrated) wrapper around libav/ffmpeg so any idea using mpv is a non-starter. It's also not required since libplacebo can be integrated with ffmpeg, as mpv (which is based on libav/ffmpeg) does.

However, libplacebo is intended for x86_64 architecture devices using OpenGL/Vulkan, which doesn't align with ARM SoC boards that use OpenGLES; althrough really it's about the formats used and where to implement the shaders required. The zero-copy pipeline we use with GBM also poses a challenge as it assumes you take a raw decoded frame and move it through the pipeline to the output stages without copying (or transforming it in software, which inherently requires copying). Hence ARM SoC's handle transformation in hardware during decoding (while extracting the raw frame) or in hardware using a image post-processor in the output stages. As mentioned before, RPi5 is lacking those hardware functions.

NB: Tiben20's current experiments are targetting Windows.

Quote from grackle

wifi on a Radxa Zero 3w appears to not be recognized

The initial dev samples of the Zero3W had a Broadcom WiFi5 chip. The release versions were 'upgraded' to WiFi6 with an AIC8800 chip that has no drivers in the upstream kernel, which is probably why the WiFi/BT nodes required to use a driver that doesn't exist have not been added to the device-tree file.

Radxa have an AIC8800 driver in their repo: https://github.com/radxa-pkg/aic8800 but LE has no interest to add downstream vendor drivers to codebase unless there is a visible/known plan to upstream them (so we can drop them once upstream).

Please push device-tree changes to a public git repo somewhere or share a patch file here so I can see the changes required.

NB: I'm currently helping with the upstreaming of https://github.com/jefflessard/linux/tree/tm16xx which adds support for the VFD displays in most Android STB to the mainline kernel. Also see https://github.com/jefflessard/tm…ree/v4-feedback. The kernel driver and userspace packaging is still undergoing some changes, but works well.

Please ignore. It was late (for me) and I've gotten confused with another thread where the user is looking for drivers and I added a patch. There are no changes in the GBM image in my share, it was for testing something else.

treedav I've picked the Armbian patch that Yasai-san flagged, and pushed an updated image to my test share. On reboot the card should now be detected, but firmware will be missing. Check the system log for errors and filenames.

See https://wiki.libreelec.tv/how-to/add-firmware for instructions on manually adding firmware. This repo has firmware files with a blind guess at the needed filenames: https://github.com/chewitt/brcmfm…re/tree/ap6275p

https://forum.armbian.com/topic/36744-or…dComment-214649 suggests this might not be enough, but best to try. If it does work I can send the patch upstream and add the firmware to our collection. Please share the journal log, e.g. journalctl | paste and share the URL.

AxelSat update to the image I posted to my testing share and then share the system log .. let's see what happens

Quote from treedav

Can anyone provide some instructions on how to get the wifi chip on an orange pi 5b going?

Run "journalctl | paste" after boot and share the URL generated so we can see which device-tree is being used, and assuming it's one where WiFi/BT are described, what chipset is being used and what firmware might be needed.

From release notes: https://libreelec.tv/2025/08/15/libreelec-omega-12-2-0/

"The nVidia Legacy 340.xx driver remained usable for six years after nVidia discontinued support, but it no longer compiles with the latest Xorg release so has been dropped from the Generic-Legacy image for LibreELEC 12.2 and the future 13.0 release. This impacts older nVidia cards, which are unfortunately the majority of active nVidia installations."

So LE 12.0.2 is the last and final working release for an ION device. I've done tests with Nouveau but VDPAU support is "not where it needs to be" for reliable use (and Nouveau only supports it on a subset of cards) and the Atom CPU on ION devices is too weak to handle software decoding as an alternative.

PAPlayer is the native/internal (and on LibreELEC the only) audio player that's used in Kodi, as we do not support the player being changed. Changing the audio or video player used to be a thing in ye olden XBMC days. I haven't seen it being discussed in many years and I'm not even sure swapping to another is still supported.

If the board powers up (LED's come on) the device is not bricked (esp. for something booting from SD media). It can have software issues that disrupt boot, but it is not bricked.

Add ssh to boot params in exlinux.conf to force the SSH daemon to start. Add video=HDMI-A-1:1920x1080M@60D to stop the kernel defaulting to 4K60 modes the TV might not like. If you want us to do more than blind guess at the issue; attach a serial UART cable and pastebin/share the output from boot.

NB: You can also try: https://chewitt.libreelec.tv/testing/LibreE…ockpro64.img.gz

Perhaps look at https://github.com/add-ons/plugin.video.vrt.nu/issues for info on current issues with that addon. If the VRT content is both geolocked and encrypted it's possible that a specific or minimum libwidevine version is required, and as the add-on authors are always one step behind upstream changes there are occasional delays and breakage while things are adjusted. In some cases it's possible to manually download and mod things but we don't track that here, and there's not much point in me trying to test VRT Max as I'm ~6,500km from Belgium.

Random MACs cause issues with ConnMan as the 'service' identifier is derived from the MAC, e.g. ethernet_b827ebb5e9a8_cable so randomly generated MACs mean a new (unconfigured) NIC on each boot.

That said, I would still expect the second NIC to be detected and brought into an UP state, and for it to receive an IP via DHCP, which will mean you have two NICs in the same subnet etc. - but that's generally not an issue, and you can add a static DHCP reservation in the router to avoid manual configuration on the LE side.

See if this works to assign a static MAC:

nano /storage/.config/udev.rules.d/99-network-custom-mac.rules

Create that ^ file with the content below:

SUBSYSTEM=="net", ACTION=="add", KERNELS=="0001:04:00.0", PROGRAM="/sbin/ip link set %k address ae:7f:66:a5:82:77"

Reboot to see if it works. Check the MAC assigned, then reboot again and check again to see if it changed? .. and if no, has the NIC been detected properly this time?

There are several K22 database API version bumps in recent time, so depending on what version you are updating from and to; the system may run a database upgrade in the background on boot. In theory Kodi should be showing the splash screen with a status message when that happens, but I can't put hand on heart and say that I've always seen it. So if you see a black screen, SSH in and check the kodi.log to see whether that's happening (or not) before forcing an update.