Posts by chewitt

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

Is "wait for network" enabled in LE network settings? If no, enable it else Kodi can start and will attempt to connect before it's available and DB connectivity doesn't wait/cycle, the connection either succeeds or fails. If the network is now up (presumably, to get logs) you can also run "systemctl restart kodi" and it should connect to setup the DB. If no, then it's some other issue like trying to connect to an outdated MariaDB version; although that normally flags a different error.

frankvw Create an SD card using https://chewitt.libreelec.tv/testing/LibreE…-11.80.0.img.gz

There will be an 11.0.4 release, but we'd prefer to wait until we can include a Kodi 20.2 release; which is currently snarled up in Android app store API version complexities that don't have a simple conclusion. Until then use an LE11 nightly https://test.libreelec.tv/11.0/Generic/

I had a quick look in our crystal ball but couldn't see anything

The download error was temporary (something being rebooted) but that's not any use since it won't contain ntfsfix. So what system do you want to test the change with? RPi4?

Currently the u-boot environment on eMMC is configured to look for CE boot files and doesn't find them (as LE files and CE files are not the same) so it falls back to Android. You need to invoke recovery boot to force u-boot into searching for bootscripts on the SD card that tell it what files LE uses. Once that's done it will boot into LE (and not CE). In the event you wanted to switch back to CE you'll need to repeat the recovery boot process so it re-learns which boot files CE requires.

Check and ensure the Kodi desktop resolution is 1080p not 4K?

I never use CEC so can't speak about that, but AFAIK it should work. I disable it in my AVR to prevent multiple test devices from fighting over who has control of the TV

If the board is booting from eMMC it's probably using an older u-boot version that shipped with the Debian image, and that might result in odd behaviour when partnered with newer kernels. I'd suggest erasing u-boot from eMMC so the board can find/use the version on the SD card, and also to use a current LE12 nightly to benefit from newer kernels and any fixes that have been made.