I'm not sure we bothered to create one, because it needs changes which I never got around to submitting before the release was cut. I'm not sure I will have time to do much in the next couple of weeks, but I will see if I can remeber to dig my Cubox-i out and test again.
NB: Right now there's not a huge difference between LE 10 and LE 11 nightlies (apart from the number) .. go see what happens.
C2 has issues with USB generally (even in the old vendor kernels) so YMMV with USB booting.
What GPU is in the laptop? .. this will be the main factor that limits your options with newer images (depending on what's inside)
Add "TimeoutSec=30" to the [mount] section and see if that works? .. i'm not sure what the defaults are.
If that doesn't work, the alternative would be to create a bash script with a working sequence of mount commands, then execute the script from a systemd .service file with right before/after dependencies for Kodi use.
Can I fix the dtb file?
In the old forum thread you found the user has a generic S912 image where you must configure the correct dtb file for the box to boot. In the LE10 C2 image I shared everything is correctly preconfigured so the dtb does not need "fixing" to work.
See if "boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2" work (edit the exlinux.conf). If not, I have no idea what the problem is.
blackride The bootloader is unable to find a partition with the label "LIBREELEC" to load the SYSTEM file. It has nothing to do with the device-tree being used. The LIBREELEC label is used with the FAT16/VFAT partition on the .img file we use for imaging SD cards and eMMC modules for the C2 board and the configuation is defined in extlinux.conf where we set boot=LABEL=LIBREELEC and disk=LABEL=STORAGE. If you have swapped between Olegs images (which used non-standard u-boot bootscripts and locations/naming sometimes) and mine or LE10 nightlies the extlinux.conf might be wrong (see if UUID or /dev/device works instead of LABEL). Sometimes sudden power-off without shutdown will result in card corruption; normally fixable with fsck. It's hard to comment without knowing the history of the device, e.g. what was originally installed, from where, and when, and what update was performed.
NB: I've run boot tests with LibreELEC-AMLGX.arm-10.0.0-odroid-c2.img.gz on SD card and an eMMC module and (from a boot/install/run perspectice) the image works fine for me.
It looks like a bug in our settings add-on. The workaround is to login via SSH and run "bluetoothctl" and pair the device from there; it's the same process just a different interface.
If i lower resolution to 1080 than everything plays fine, but obviously defeats the purpose of buying a 4k TV!
Set the desktop to 1080p and then use the whitelist to facilitate 4K playback when it's needed. Your TV will do a better job of upscaling 1080p and 480p SD media to the native 4K panel resolution than Kodi (on an ARM SoC) will.
The feature request is: User saves bookmark in browser and this populates a link to the "favourites" list in Kodi, so in future user can click the favourite and go directly to the URL in Chrome. In the sense that "it's only code, everything is possible" .. it's possible. Back in the real-world I don't see anyone volunteering to code it though, especially since we plan to ditch X11 which kills the current add-on.
The command output shows you not following instructions 
You've noticed the "u" option in emmctool, which writes u-boot to the 1st and 512th sectors on the emmc storage. If you stopped at this point it would have worked. Then you "w" the LE image to emmc which overwrites it with an image containing MBR structures in the 1st sector and u-boot in the 512th sector. This would work on GXL and newer devices which check the 512th sector on emmc, but not a GXBB device which only checks 1st sector. Then finally you dd u-boot directly to emmc again which puts it in the first sector again.
The image has some audio issues. I'm unable to get 48KHz media to output unless I force Kodi to resample it to 44.1HKz. I don't see this on GXL/GXM devices using the same image. There is also a "machine gun noise" buffer underrun which occurs. You'll know it when it happens because your ears will bleed - You need to toggle the audio source in Kodi to fix it. In both cases I have no clue where the problem resides - and I'm not really a coding developer with the skills to investigate.
I don't do the beers thing. The project accepts paypal and open-collective donations though.
Three suggestions - in order of best to least-best:
a) Switch to Ethernet
b) Switch to Ethernet connection to a wireless bridge
c) Fix the network so it doesn't have dropouts (harder than it sounds sometimes)
In B .. because the Ethernet link to the bridge device remains up at all times you don't see a dropout which results in the connman 'teardown' that you see when the link is lost on the wireless connection.
Start a thread, provide debug logs.
One's a scheduled nightly. One's probably a test build someone spun for something. 
Yup, my WP2 image: LibreELEC-AMLGX.arm-10.0.0-wetek-play2.img.gz which has the magic header in the 512th sector of the image, so if you write the image to an SD card using something like etcher it should boot (mainline u-boot) on the box.
There are two issues:
a) I'm still jetlagged and a bit distracted after vacation, which means I forgot something rather important
b) You've erased u-boot
GXL (S905X) and newer boxes look for a magic boot header in the 1st sector of emmc or 512th sector of emmc or SD or USB, but older GXBB boxes like WP2 only look for it in the 1st sector of emmc (or 512th sector of SD or USB). The problem is, the first sector is also where the MBR partitioning data lives, so you have the choice of partitions and no-boot, or boot and no-paritions. Amlogic "vendor" u-boot implements a custom offset-MBR partition scheme to workaround the design mistake (which is corrected from GXL onwards).
If you connect the UART cable (WeTek did ship them with the box) you'll see it endlessly looping with something like:
"GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:800;NAND:81;SD:0;READ:0;CHK:0;"
It's not bricked. It simply means it cannot find the magic boot header. The normal way out of this is to write the "wetek-play2" image to an SD card and leave it connected. It will then boot from SD and you can tweak things to store data on emmc if desired. In your case the SD slot will not permanently latch/retain the card, but you'll need to figure out a temporary way to hold/fix the card in for long enough to boot from SD and perform some remedial steps. I would start by zero'ing the emmc (the z option in emmctool) and then "dd" u-boot.bin.sd.bin-wetek-play2 directly to /dev/mmcblk1 (no offsets, seeks, etc.). This will put mainline u-boot and the magic boot header in the 1st sector, so the box will boot from emmc, and u-boot should find the "wetek-play2" image on a connected USB stick.
The alternative is putting the original vendor image back by writing Dropbox - backup-wp2.img.gz - Simplify your life directly to /dev/mmcblk1 and then rebooting. This is a raw backup of my box taken a couple of years ago .. but should work.
Apologies again .. I'd completely forgotten that GXBB has the extra hoop to jump through.
Please explain in technical detail how you have diagnosed the problem. I'm not disputing PMF might be involved, but we need to discern facts from enthusiastic opinions and hunches before we attempt to engage upstream Engineers.
Installed v. 10.0.0 on my Rpi4, but no sign of HDR playback. Did I misunderstand something? Can this version play HDR files?
HDR works fine here for 6+ months now so if you're having problems, it's a Layer-8/PEBKAC issue.
WP2:~ # modetest | grep connected
31 0 connected composite-1 0x0 2 32
34 33 connected HDMI-A-1 1600x900 27 33^ from an Amlogic device .. "composite-1" is present. Allwinner also uses the kernel DRM framework so something similar should output. The Amlogic section in the wiki is not relevant (old kernels).