LibreELEC.tv/smb.conf at master · LibreELEC/LibreELEC.tv · GitHub
LibreELEC-Generic.x86_64-8.1.2.ova
If you want to test in a VM first grab the OVA ^ and import to vmware Workstation/Fusion etc. - You need to set the number of CPU cores, RAM size, networking and expand the HDD to about 8GB before first time boot. After that it just works. No idea if it works in other VM apps, it's only used in the team for testing and we all have vmware stuff.
/storage/.config/shutdown.sh^ create that with your commands inside
Things that override in /storage/.config are limited - it's not everything but most of the useful ones.
One of the connman devs has confirmed that READY and ONLINE are basically the same; only with ONLINE you know it's capable of reaching the public internet without proxies, captive portals etc. in the way. Not relevant for your needs but something I'll bank in the brain. I forget why I added the connman_main.conf trick now, but glad it's come in useful eventually 
It's not always possible, but always preferable to fix the server end to support SMB2+ connections instead of forcing the client end back to ye olde (insecure as hell) SMB1.
Now that PEBKAC was confirmed for the main problem. What exactly are you trying to boot LE on? - Etcher is normally overkill but fine for creating working images for supported hardware.
No Kodi debug log = no problem
Kodi doesn't support miracast so LE doesn't support miracast. On some Android devices the Android OS supports miracast; hence some of the blog posts etc. that you've read.
That shows a box that boots with no network connection and then does nothing. Probably because it's a crash log and not the normal kodi.log
A small question, the minix neo u1 will never be updated to marshmallow ?
Please go ask minix about their plans for Android directly. This is a forum about Linux, not Android.
Amlogic kernels don't natively present hardware to alsa correctly so alsa isn't able to auto-configure things. We cleaned up their shitty coding for HDMI and S/PDIF but analogue hasn't received the same love (it isn't the same priority) and I wouldn't be surprised if it only works on limited devices and generally remains a bit broken. In the long-term Amlogic kernels are being completely re-written, but Amlogic chose to outsource that work instead of doing it in-house (not a bad things considering the quality of previous work) but they are proving to be dog-slow at funding the remaining parts we need (admittedly large and complex parts) before we can move up to a mainline Linux kernel.
I'm guessing at what's happening here .. but most archival tools work by assembling a copy of the data first and then they write that collection of data to the archive file. So if you have 2GB of original data on disk, the temp cache will also take 2GB and then you write the file (compressed) which is maybe 1.7GB, so you end up needing 3.7GB free on the disk to backup 2GB. Even if the final write is to a different disk (e.g. connected USB) you need 2GB on the original disk before it writes the 1.7GB to USB.
So I don't know how much data and free space you have on the USB stick, but most people running from a USB stick have small(er) capacities. The solution would be to stop kodi (systemctl stop kodi) and then recurcively copy files that you want to "back up" to another USB device, e.g. cp -R /storage/.kodi /some/other/device as the copy operation isn't assembling a grand copy of all data first.
autostart.sh is user created content that lives in /storage/.config so it will not be touched by the update process
If/when opdenkamp fixes libCEC (with a well tested patch) and pushes the update to Kodi's git repo we will pick-up the update. Until then, as is normal for anything related to libCEC, there is a long wait involved. It's never code that we rush to change because fixing one things frequently breaks things for someone else. In the long-term we'll move to the new in-kernel CEC framework and drop libCEC which will improve things by removing the dependency on a single developer.
Debug logfile please
RPi hardware is a little fantastic miracle from a price/performance perspective and its ability to "hardware decode" 1080p video etc. but this is all about CPU and I/O from accessing the DB file. Your Chromebox has ~20x the CPU grunt of the RPi3 and probably uses higher spec/speed flash for the internal storage which is why it has no visible I/O issues. 50k FLAC files tells me you're really into your audio and quality.. so it's time to do the collection justice and get a second Chromebox (or similar).
echo "client lanman auth = yes" > /storage/.kodi/.smb/user.conf
systemctl restart kodiSee if ^ resolves the problem. If I remember correctly the server doesn't support NTML authentication.
No idea. First I heard of that issue. Kodi debug log from a clean boot and demonstrating the problem would be a good idea.