Posts by chewitt

Quote from Yasai-san

I can't find yet which commit affects it because v2025.10-rc1 has 1025 commits from 2025.07.

RK3588 boards should be usable without the additional patches that LE is using (which are mostly for 3576 support) so clone u-boot sources and start a git bisect to track success/failure, but use the githashes (and no patches) in the LE buildsystem. No matter how large the number of commits difference between the start points is, bisect will find the breaking commit within 8-10 moves, and if the rest of the LE image is static this is probably no more than an hour of effort. NB: I normally edit scripts/uboot_helper so I don't waste time building images for hardware that I won't be testing with.

Quote from tech

what can you recomend please

We recommend you find a forum that allows discussions on "which is the best VPN provider" .. because this isn't one.

Do a force refresh of the repo from the add-on browser.

It's interesting that it reports invalid key, because it should report invalid passphrase. Otherwise it's not the eureka moment we are seeking. The \ character is not an allowed character for passphrases and is thus rejected, end of story.

The 'invalid-key' other folks are seeing is a crypto key being exchanged between client and access-point, and it's deep in the guts of the negotiations needed for some radio features. Weak signals tend to surface it more, which suggests it's related to error handling (or not-handling) code somewhere in the wireless stack. It also shows up with Broadcom WiFi hardware and WPA3 which is not fully supported in current kernel drivers for that hardware; although we've applied mitigations for that now.

I've removed "[SOLVED]" from the thread title because I don't want the noise of others pointing out that "there's a solution you're not telling us about" and/or that your solution doesn't work for them.

There is nothing to stop you or anyone else building an own LE image with extra features or support for things we dropped patched or hacked back in. That's the value of open-source software and distros that provide sources. Go nuts. Have fun.

LE Settings > Services > Samba > enable "Use Samba Password Authentication" and then change the libreelec users' default and well known libreelec password. Windows should be happy with that and there's no need to disable any security settings that MS will inevitably force back to 'on' again in some future update.

HDMI-CEC is almost never present on x86_64 hardware because NUC style devices are envisioned as Desktop PC's to be attached to a monitor, not an HTPC attached to a TV/AVR.

U-Boot SPL board init
U-Boot SPL 2017.09-orangepi (Aug 30 2024 - 22:09:16)

Yasai-san all three boards are trying to boot a prehistoric vendor u-boot, e.g. ^

I'd guess they have it installed to SPI flash, so erase that and the boards should find upstream u-boot on the SD card and boot.

Amlogic u-boot uses a proprietary partition scheme with Android boxes and this is not supported by any upstream disk/file tools and we aren’t interested in adding the downstream stuff in LE, so you are limited to booting from an SD card or USB and we need to hook the boot process to load the LE kernel etc. SBC boards like the M5 are supported in upstream u-boot so we can support install to eMMC on those via a two step process (boot from SD, then download and write the LE image to eMMC).

If your box will boot upstream u-boot created from the boot FIP sources of another known (supported) device then you can engineer upstream u-boot support, but this requires experimentation that starts with erasing eMMC so you need to be familiar with Amlogic recovery tools and have the original ROM image and have a serial UART cable wired up to see what’s going on during boot. It’s not something that we support or guide users through because most users don’t have the tools or aptitude for the task. Self-recovery when an incompatible u-boot has been written and you need to short pins on chips to bypass it is not for the faint hearted.

Yasai-san please see https://github.com/LibreELEC/LibreELEC.tv/pull/10495 which the patch descriptions show also touches on some RK3588 boards. I pushed updated images to my share about 30 mins ago.

It's been dropped and we have no plans to add it back as it will only break again, with 'weeks to months' the normal timeline to another fix, which will be another patch that can never go upstream because; a) there isn't one, b) the driver is abandoned.

Quote from il5algo

Is it normal for emmctool to tell me "Your device is not supported!"?

100% correct .. "The emmctool helper supports a limited range of SBC boards with eMMC modules. On a generic Android device it will output the (i) info only." .. see https://wiki.libreelec.tv/hardware/amlogic#emmctool

I don't see users here or in Tvheadend forums complaining about RPi5 and TV HAT issues. That could be due to nobody using that hardware combination, but given the overall volume of RPi5 boards and prevalance of people using DVB capabilities among our userbase I'd expect any lingering issues to surface.

LE13 nightlies are currently using 6.12.42 (and 6.12.47 from tonight) so if any fixes exist in the RPiOS kernel, we have them.

You need to force recovery boot again. This forces vendor u-boot to search for bootscripts that configure it to look for the boot files that AMLGX uses, which are not the same as legacy images. If you don't, vendor u-boot is looking for files that don't exist and (as you found) boot will fail.

I've merged CI changes so LE13 nightlies should commence in the next 24-48h. There's a probability of boot issues with RK3576 as the Rock4D that I have boots and runs great .. for 30 seconds .. then the board stops responding.

There's also a Rock 3C gathering dust that needs to go into the test rotation so I can look for issues.

I'm not aware of any other issues, but ignorance is bliss

The most likely candidate would be the kernel bump to 6.16.7, as other changes in the timeframe are either graphics packages or support for various ARM SoC hardware platforms, not x86_64.

First step is to revert to Estuary and confirm whether it's a skin issue or something in Kodi core itself. Second is to report the issue to the correct location, either the AZ skin developer(s) or Team Kodi, as LE is not patching/modying profile behaviour in any way.

I've submitted https://github.com/LibreELEC/LibreELEC.tv/pull/10493