Posts by chewitt

The log shows no attempt to switch to HDR modes which implies HDR isn't exposed as an option through the kernel rendering system which implies the Intel GPU drivers in the kernel we are shipping (also the latest available) don't support HDR. Updating firmware doesn't change anything in the kernel drivers, and comparisons against other OS (with entirely different software stacks) aren't meaningful.

It would help to see the EDID info which is logged in kodi.log on startup; this doesn't show as you've enabled debug after boot.

The issue and latest findings should be reported upstream to the Pi devs via their GitHub tracker (as advised in post #62 back in March).

The upstream kernel switched IR keymaps to the "toml" format so I'd guess you need to make the same changes in your file. Have a look at the keymaps in /usr/lib/udev/rc_keymaps/ to crib the format changes (not hard).

Your Q was already answered: https://github.com/LibreELEC/LibreELEC.tv/issues/8322

If the same file being played by the same K21-b1 version of Kodi on Windows works, the issue is likely to be Intel drivers, in which case our normal course of action is to simply wait for Intel to finish adding support for their latest/recent chips.

WiFi is conected via the SDIO bus which supports device discovery, so even if the device-tree file you're using describes a Broadcom wireless module (as is the case with all the generic reference designs) the bus is probed and if a Realtek device ID is found the correct driver will run, and as long as the firmware is available WiFi will work. BT is different; it's a serial UART device and requires device-tree to correctly describe the hardware, and if a Broadcom chip is the 'compatible' hardware described a Realtek chip doesn't work. The solution to that is creating a dedicated device-tree file for the box. It's not a particularly complicated process (fairly easy to copy/paste) but still requires you to then create kernel patches and self-build an LE image and most users aren't interested in having a go.

I replied in the other thread.

https://github.com/LibreELEC/LibreELEC.tv/pull/4566 <= That's the PR that dropped support for Slice boxes. In there you'll find the original add-on that FiveNinjas created and LE buildsystem package.mk files that tell you where the drivers are. Compile the drivers for your OS and then use the add-on (or use it for inspiration on how to control the LEDs). The only barriers to doing things are time and effort.

The percentage of x86_64 users peaked around 30% in the early years of OpenELEC then gradually declined to a stable 10% figure in recent years. For a long time the main driver was probably Pi boards being cheap and good value. These days they're a lot less cheap; but then the alternatives have also risen in price so the status quo has persisted.

1080p or 1080i media? .. interlaced media needs different settings enabling (read https://wiki.libreelec.tv/configuration/4k-hdr)

echo "0b05 18f0" > /sys/bus/usb/drivers/<module>/new_id

The kernel probes for USB hardware and the dongle is visible on the USB bus, but the driver is not being loaded; so the driver in that (rather old) 4.19 kernel doesn't support the card. The ^ above approach used to be supported for adding unknown IDs to a driver from userspace but I didn't use it in years so no idea if it still works. You need to replace <module> with the module name. NB: In current kernels (Linux 6.6) the correct module name is "r8188eu" not "8188eu" but this is likely the newer in-kernel module and not some older realtek vendor driver (prob. with a different module name) that might be in older LE images.

I'd start with a current LE12 nightly image as that kernel should support the card. If you then need to go backwards in time for better RPi2 hardware support move to LE 9.2.8 and retest again. I have no recollection now of what LE release used 4.19 kernels.

Ahh, that explains then. Thanks for clarifying. We're contemplating where we go with changes..

Copying binaries between different LE major versions or from other distros occasionally works but is never guaranteed. I'm going to have a look at Ubuntu 18.04 and what it's doing (need to find something with an Intel CPU for this though). I'm wondering if they have udev rules that run ntfs or they aliased a script that runs ntfsfix to fsck.ntfs. I'm 100% sure the util-linux tools support FAT/VFAT but do not support (and never have supported) NTFS; so the output from the fsck command needs explaining.

The sequence you're describing proves the box is booting from eMMC. CE (and LE) are both dependent upon the vendor u-boot install which resides on and boots from eMMC storage. However, when you run recovery boot, either via the "reboot update" command or from using the reset button, vendor u-boot looks for u-boot script files, finds them, reads them, and this modifies the early boot environment to look for non-Android boot files. CE and LE use the same process to subvert Android and boot Linux, but configure u-boot to look for slightly different boot files. Hence after converting the box to CE and then triggering recovery mode (reboot update) with the LE card inserted it searches for and finds LE files and no longer finds CE files. To switch back to CE (either on SD or eMMC) you need to invoke recovery-boot mode again. This is normally done using the reset button: press the button (and keep it pressed) then power the box on and release the button at the right point (typically 6-7 seconds into boot) and u-boot searches for boot files again and will find CE scripts on a CE creted SD card. It's not a simple button press after power-on and LE has no ability to run "reboot update" commands that need Amlogic drivers that don't exist for newer Linux kernels. Now, it's unlikely but not impossible that your box vendor hacked Amlogic u-boot code to remove support for recovery boot and the button does not work. It's also possible that due to age or abuse the reset button has mecahnically failed. In that case you can still recover the device back to Android using the Windows based Amlogic flashing tool and a factory recovery image for the box, which are often found on vendor websites or forums like 4pda.

See what happens if you place LE boot files (on the LE SD card) with CE boot files (SYSTEM, kernel.img and the correct dtb.img). Rename kernel.img to KERNEL and configure uEnv.ini to look for a dtb file called dtb.img). Not guraranteed to work, but simple to try.

The Slice add-on that managed the LED ring in the background is Python2 based and wasn't migrated/updated to Python3 which is needed for compatibility with LE11. You can cross-grade/update the main OS to LE11 by switching to the RPi2 image, but the LED functions will stop in the process. Cross-grading requires you to SSH in and download the RPi2 image to /storage/.update and "touch /storage/.update/.nocompat" to override the compat check which will detect a non-Slice image and abort the update process.

The tool that I added to the image is "ntfsfix" not fsck. Please test that.

Yup, run the test image from a USB instead of the internal drive.

I'd suggest using an LE12 nightly which has newer kernel/drivers for the GPU card. Improved?

There are numerous iterations of these demo files available on the internet. Some have normal timestamps and encoding and some have been "remixed" resulting in strange or broken encoding that causes the kind of problems that you're flagging. Using the same files I see the same issues on RPi5/LE12 (same drivers/codebase as RPi4): audio playback on the Barcelona file starts within a second but I initially see the 'buffering' spinner, then a black screen, and it's approx. 16 seconds before the screeen switches to 4K and video appears.

TL/DR: You should watch movies not "test" media. I don't see any issues with real media.

popcornmix ^ for reference, some new content for the broken file collection