[ 12.876758] meson8b-dwmac c9410000.ethernet eth0: no phy at addr -1
[ 12.876792] meson8b-dwmac c9410000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19)Ethernet works fine if the box follows the reference design. Not all boxes do. It would help to know what the box is? .. and if possible to get the Android device-tree file, or be told what device-tree has been used successfully with other distros like CE.
Patch the code so that both calls use g_memdup ?
I will have a copy of the file in a clone of the LE image archive (which is currently offline) but the 9.2 release images will be a lot more reliable than some early alpha build. Also, there will be no add-ons for that image now, becaus ewe normally delete the alpha content to save space on the server once final releases have been out for a while.
You can/could bastardize something in pulse to do this, but it will be complicated as hell to configure and prone to timing issues so I just wouldn't bother. Save pennies and get a proper HDMI 5.1 surround speaker arrangement. The result will sound better and be zero effort.
For unexplained remounting of drives I'd suspect either power, or perhaps running out of RAM causing processes to be killed/cycled which can result in things being in odd states (not specific to LE, but a general thing with any Linux distro). Enable persistent logging and then do some log review/reading.
LE10 (stable) and LE11 (stable but still pre-beta) images can do everything that LE 9.2.8 can do. Use them; they are greatly superiour than LE 9.2.8 now. If you have an issue with those images; state the problem.
It took me 10 seconds to find this in Google: https://forum.kodi.tv/showthread.php…4738#pid2484738
Kodi has no support for tonemapping and is unlikely to gain that capability anytime soon. Most hardware Kodi currently runs on either lacks the specialist image manipulation capabilities to do on-the-fly tonemapping, or the hardware can do it, but support hasn't been implemented in the Linux kernel and drivers yet; and hence there's no need (and not much point) trying to support it right now.
In simplistic terms: Kodi simply outputs video with an appropriate resolution, colour depth, colour-space, and HDR flagging as detected from the media being played and within the constraints of what the hardware (HTPC) can output. As not all hardware supports all combinations (read from the HDMI EDID data) Kodi will sometimes output in a higher bit-depth or nearest colour-space from possible output formats. It's then up to the display device (Monitor/TV/Beamer) to figure out how to display that combination.
Experiment with the connmanctl move-before/move-after options, as this will change interface priority and influence the routing table.
There is no support in AMLGX for the internal tuners - there is no V4L2 demux in the upstream kernel.
There's nothing enlightening in the dmesg log (as was expected). It's an odd one.
Please run "dmesg | paste" and share the URL, to see if there are any error messages in the log?
The one remaining experiment I can think of is writing the WP2 (not box) image to emmc. This replaces vendor u-boot with upstream u-boot and changes the early boot process. That said, I'm not sure it would resolve anything as I've not had other reports of what you're seeing and there's a growing number of users (most of whom are probably booting from SD card). I have a raw (dd) copy of the original factory image that can be restored to emmc if you wanted to put Android and vendor boot code back.
https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz
To install to emmc download the WP2 image to /storage/ and then run "emmctool w LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz" and it will install everything. To restore the backup, boot the WP2 image from SD card (so emmc is not in-use) and then download the backup and write it with "emmctool w backup-wp2.img.gz" .. until it eventually finishes.
LE fixes a kernel major version for a specific release and then sticks with it. So LE10.x is built around 5.10.x (on RPi at least) and on LE11 we're currently at 6.0 but will probably end up on 6.2 by the time we enter beta and lock the kernel version. There's no trick to it, or penalty for being on 5.10 in the current stable release. If you want to replicate our stability you'll need to replicate all the same major versions and the patches that we use; kernel, kodi, mesa, firmware, etc. - it's not just the kernel.
Kodi has no Game/ROM library so there's no way to pretty things .. except for Favourites if there's a small number of files.
Mapping e.g. 6x channel audio to 3x stereo audio jacks is possible using a custom alsa configuration file. However, we do not provide the file or any instructions on how to do that.
There are several people on staff with RK3588 boards including the Rock B. There's quite a few drivers to be written before we'll be able to create usable images though so I wouldn't get too hopeful of seeing anything soon 
I've long advocated that if you want reliable DVB with LE or any of its derivatives you should separate the head-end from the client, because it makes it much easier to e.g. run RaspiOS on the head-end (easy package installs, any drivers you like, older kernel, etc.) while the client side runs LE. Separating things allows you to keep the client current, bumping as frequently as you like, while the server side remains on whatever works (and no need to bump it).
Exactly. I booted from SD card.
Thanks for confirming. Fix has been merged for future u-boot releases: https://source.denx.de/u-boot/custodi…d6d1937075153b4
