Posts by chewitt

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

il5algo the AMLGX image mounts filesystems using GUIDs not /dev/device references so have you changed the boot params in uEnv.ini? - What distro was installed before?

Most streaming service "geo" blocking also includes the ASN ranges of known hosting providers, so if some VPN provider operates their London infrastructure from well known London hosting centres (or simply their ASN's are known) then their IP ranges will be blocked.

Quote from wyup

Only Libreelec 13 with conman/iwd.

Go repeat the experiment with RPiOS on the same hardware.

Look at the systemd journal and kodi.log. One of them should have clues.

This is more likely to be a Kodi (software) issue not an LE (packaging of software) issue; but some ideas in no particular order:

* Go backwards in time with nightlies and pinpoint the first date when the issue appears. We can then look at what packages changed on that date. I'll guess that the main package bump will be 'Kodi' .. but then we can look at what changed between the previous Kodi version (tracked through githash) and you can start a conversation with Kodi developers around that.

* Switch to the default skin. If the issues go away, it's either an issue with Arctic Fuse2 skin itself (something to take up with the skin developers) or the skin triggers a rendering problem (something for Kodi developers). If the issue remains; it wasn't the skin.

* You have a large number of add-ons installed. Switch to a clean environment (stop Kodi, rename /storage/.kodi to /storage/.kodi-old and restart) and then start to add back add-ons until you find the one(s) which trip the problem.

This is a TV underscan problem and not an HTPC hardware or software problem.

HDMI ports are not always equal. If the TV has other ports, move the cable around and see if any of them work better? See if any are configured for 'PC' use and if possible set them to 'normal' (or some other) mode. You can also see if changing the default desktop resolution from 1080@60 to 1080@50 in case this generates a better outcome?

The option of last resort is to 'calibrate' the output via Kodi settings > System > Display > Calibration. It's the worst option because unlike a CRT tube where calibration mechanically adjusts the spread of the electron beam to better fit the screen, this change is digital and done in software. Calibration forces Kodi to squee``ze e.g. 1920 x1080 pixels into 1900 x1060, with the remaining pixels to make up 1920 x 1080 rendered black. It's a lossy process and 'squeezing' the image can lead to other visual artefacts in playback.