I've reported the warnings to the repo owner: https://github.com/jwrdegoede/rtl8189ES_linux/issues/106 .. but don't hold breath.
You should be able to run the image from SD or USB cards. It still boots from eMMC, but the boot routine is modified to search for LE files on SD and then USB devices. In past testing I've found that some vendor u-boots struggle to init USB support and thus cannot find the device to boot from, but those seem to be the exception not the norm.
Here's a question to any fellow Pi 5 testers, are there actually any media files that a Pi 4 could play that a Pi 5 can't?
Nope. RPi5 handles more than RPi4 which handles more than RPi3; except for 3D which neither RPi4/5 support.
You have banned add-ons installed. So no support in this forum.
I'd use an RPi5 board. It's probably cheaper, uses less power, and not a large performance difference.
I'd use the 3840 "4K" modes: have a read here: https://wiki.libreelec.tv/configuration/4k-hdr
I'd probably use "WantedBy=multi-user.target" instead of kodi.target, but if it works, it works 
You can use "kodi-send" to send commands to Kodi, including PlayerContol() for starting a playlist. You can put individual kodi-send commands or a sequence into a bash or python script that's called from a systemd service; allowing you to schedule execution of the script once Kodi is up/running (with a small delay so background things have settled before you start playback). If you need to, you can also query DB files for the content to (re)create the playlist from.
Things you can do with kodi-send: https://kodi.wiki/view/List_of_built-in_functions
I'd also consider capturing essential Kodi configuration files and using another script + systemd service to schedule and restore them before Kodi starts; so when the inevitable random or accidental pressing of wrong buttons screws with Kodi config (esp. media views) you can revert to the predetermined configuration with a simple "turning it off and on again" action.
Good luck
That's not a debug log, and no playback problem is demonstrated.
I make no claims on understanding Meson 8 boot. If changes are needed I merely ask that people point them out
dtech I think the idea was to get the box booting any non-Android OS first, and work forwards from there.
The current u-boot bootscripts in the AMLMX image are a mashup of various things i've seen/read and blind guessed at since I don't own any Meson 8 box devices that can be used for testing (only a C1+ which has a tweaked/customised u-boot environment and a WeTek Core that doesn't boot). In short: I'd be really surprised if they worked
If you share the output from "printenv" we can see the internal boot flow for u-boot and perhaps figure out how to hook the boot process (as we do with AMLGX). In current state from UART you can probably switch to the SD card root partition and boot KERNEL etc. using the content in https://github.com/chewitt/LibreE…_autoscript.src
99.999% of 4K movies are [email protected] or 4K@30 so 4K@60 modes are not normally required and they force the board to consume more power for no reason.
I have lots of original copies. I also have kids who are incapable of putting discs away in the correct box and/or without leaving them on the floor where they get scuffed and made unreadable. So all new acquisitions are immediately ripped to a NAS, which makes the entire library kid-proof and navigable without getting up from the sofa
You can share links to the Pi forums or reshare the same details here.
smp sky42 I'm wondering if any of the RPi patches related to bit-depth might avoid kernel hacking? See: https://github.com/LibreELEC/Libr…th-videos.patch and other patches in the same folder.
I think the SOC in this device is a Amlogic S905X4
There is no usable upstream support for S905X4 devices at this time, so an LE image is not possible. You can probably put CE on it, but that's a question for their forum.
using Handbrake to rip the ISO to file/files normally always works out quicker
