The build system is building pixman 0.34.0 for target so the host version being 0.33.0 is not relevant. That's the whole point of cross-compiling the packages. I've no idea what the failure is about (something bad during LTO).
If you've been fiddling with dependencies it might be an idea to run a clean build in-case the toolchains are poluted with odd stuff.
The /dev/mmcblk1boot0 and boot1 devices are special locations where (if the hardware supports them) you can install u-boot separate from a normal MBR filesystem on the /dev/mmcblk1 device, but GXBB (and GXL/GXM) do not support this. The first Amlogic devices that do suppport it are G12A (S905X2/D2/Y2).
The non-standard location is simply an offset (shifted X sectors). However this is only visible-to and understood by Amlogic u-boot which has the internal juju to understand the offset and it's own partition tools. All normal userspace apps like fdisk/parted cannot see the partitions that have been created. You can see this when booting the LE10 WP2 image on a factory state box and running "emmctool i" - it can see the emmc device but no filesystems are listed on it.
If you want the DVB tuners to work you will need to restore to an LE9 or CE9 image as there is currently zero support for the DVB cards used in Amlogic boxes in the mainline kernel. This also solves the SD card issue as the device will boot from eMMC. This image will restore the box to WeTek/Android state Dropbox - backup-wp2.img.gz - Simplify your life .. then boot from SD card (the LE10 WP2 image) and use emmctool or dd to write the file to emmc. USB should also work as an alernative to SD .. I've done it numerous times with other boxes but can't say I've ever bothered with a WP2 as mine has a working SD slot. YMMV.
Is the part I am not understanding is that I will always need the SD inserted to trigger the boot via disk LABEL on eMMC?
Correct. The SoC (hardcoded silicon) only checks for signed boot firmware magic in the first sector of eMMC, which is where the MBR partition data also needs to reside, i.e. if you install u-boot there it overwrites/breaks partitioning (but the box will boot) and if you put MBR there your partitions are good but the box will not boot (no bootloader). The design mistake is corrected in the next hardware generation (GXL) and up, which also check the 512th sector (same as SD media) which allows MBR to reside in the expected location and boot firmware to be elsewhere. So the workaround is to boot (u-boot) from SD .. it then executes the Linux KERNEL file and userspace SYSTEM file from eMMC.
The *only* way to boot *and* run from eMMC is to use Amlogic u-boot which implements a custom partition scheme that relocates the MBR data to a non-standard location. The code for this could in theory be ported to mainline u-boot, but the resulting changeset would never be accepted and would have to remain as an out-of-tree hack/patch, which effectively guarantees it will never happen.
You probably need to increase the RAM allocation to the VM. Anything over 10GB is good. Anything under will need a swapfile and time.
I am 100% confident you cannot put mainline u-boot on eMMC *and* boot into an OS that resides on eMMC at the same time. It would need the same kind of MBR coexistence fudge that Amlogic added to their own u-boot sources. This doesn't (and won't) exist in mainline u-boot so we cannot replicate the the vendor image experience. That said:
Install the image to emmc (emmctool w ...). This gives you the normal two partitions and files in the right place. Now erase an SD card and put u-boot on it in the right place, see: LibreELEC.tv/mkimage at amlogic · chewitt/LibreELEC.tv · GitHub and u-boot.bin.sd.bin-wetek-play2 for the u-boot.bin.sd.bin file.
I've never tested this, but it should boot (u-boot) from SD and then find the LE boot files (via disk LABEL) on the eMMC partition?
The version you can update to via the settings add-on menus is limited by what we have embedded into the image; which is the version we tested against that image. You can update independently via files if you want/need to. We will update the firmware as/when needed in our next maintenance release.
Stop Kodi and move/rename the /storage/.kodi/addons folder out of the way so the add-ons cannot start (and crash) when you boot into LE10 for the first time. If you leave the add-on DB files in place we should check for new versions and install them, although there will be gaps and some cleanup might be needed. I normally advocate simply renaming the whole /storage/.kodi folder, allowing the upgrade into a clean Kodi instance and then stop Kodi and move back the bits you want to retain before restarting. It's a low-tech but simple/quick process if you know what the important files are and where they live/go (most users don't, hence the general advice to do a clean reinstall).
OE 5.95.1 is the first beta for OE 6.0 so better to checkout and skip ahead to the final release (OE 6.0.3) as more bugs are fixed.
Make subdirs per-channel sounds reasonable.
See the "NAME MANGLING" section in smb.conf .. LE defaults to "mangled names = no" which means the filesystem is case insensitive and the samba default for casing is lowercase, so my (now educated) guess is the "Nova" file is the one that downloads?
Comments in the docs imply the Windows client does not support case-sensitivity so I'm not sure experimenting with a custom samba.conf will lead anywhere. Better to focus on TVH and ensure it always writes unique Windows compatible filenames (no idea how - not an app I use or have experience with).
Filenames contains "Nova" and "NOVA" and in a Linux case-sensitive filesystem this means two different files. What file is served/returned/downloaded when you click on a file?
Correct, I think the filesystems are marked dirty so you need to fsck them and remount. You can dry-run the fsck if needed, it will check for issues and report, but not make changes.
Please share Pictures, Debug Logs from TVH (or whatever makes the recording) and filesystem output (all to pastebin) to prove that two files of the same name exist in the same filesystem at the same time. That should be impossible, so we need to explain or eliminate that before pointing fingers at Samba server behaving badly in that scenario.
Assuming you are booted from the SSD, i.e. the 2G/4G HDD are not the boot device: umount the mounted drives, fsck the partitions on them, then use e2label to change the disk labels; reboot and the drives will mount with new names visible. My guess is the drives haven't been cleanly ejected/shutdown in Windows so the filesystems are marked as dirty. Linux considers dirty filesystems to be corrupted so auto-mounts them read-only to prevent damage. The fsck will clear the dirty flags and allow things to remount in read-write mode. NB: If you are only going to use the drives in LE you'd be better off with EXT4 partitions; I'd guess Windows drives are NTFS which (until Linux 5.15 appears in LE releases) will be rather slow (fast enough for local playback, but not best performance).
LE version is?
LE 7.0 was built using Ubuntu 14.04/16.04 so OE 5.0 is probably 14.04 material.
Okay, well, if you get stuck with OE things .. ask Q's. Otherwise we'll leave you to it 
If folks like bumerc have failed to understand or figure out how Armbian booted in the various CE forum threads I don't stand much chance of a eureka moment (as I know far less then them) .. so I'll pass on the opportunity for a fruitless and frustrating investigation. I'd prefer to spend my limited time for Amlogic fiddling on other dev things. Sorry.
