The "install" script is checking for an OS that uses Debian packaging (Raspbian, OSMC, etc.) so it's not going to work on LE.
Share "journalctl | paste" about 60 seconds aftter booting (with Etthernet connected) and we can see what chipset is in the device, and from there we can advise on the chances of it being supported in LE.
Ahh, the original Q is now clearer. If you have two screens attached (LCD via ribbon, TV via HDMI) Kodi will use the first one probed by the kernel, and on ARM hardware Kodi does not support multiple screens output (maybe in the future, but not today). So to redirect output to HDMI, you either need to disconnect the LCD, or perhaps fiddle with config.txt and disable in software; I'm not sure as config.txt options are not my area of expertise.
I've never used either of them (WebDAV or SFTP) so I can't really comment.
Create and run a backup script via cron that captures any directories you need, and then scp the backup to a remote server so the files are stored in an off-box location.
It wouldn't surprise me if the kenel defconfig for the NXP (iMX6) project is missing items.
We don't overwrite anything. Everything you see in the OS except for /storage is uncompressed from the read-only SYSTEM file at boot time, and we don't touch /storage during update (it's not even mounted).
@DaFlex that's running a 64-bit OS in a container (on 32-bit userspace) so not really a solution that works. Yeah, hopefully Google blinks first on the 64-bit libs at some point.
echo "ethtool -s eth0 speed 100 duplex full autoneg off" > /storage/.config/autostart.sh^ something like that should work
Recommentded settings for RPi4 devices are 1080@60 desktop resolution and [email protected]/24/50/59.95/60 and [email protected]/24/25/29.97/30 modes whitelisted. This ensures SD content is scaled to 1080p max and only 4K content is played at 4K, and we scale 720p skins to 1080p (which still ooks good) and leave scaling the 1080p GUI firther (to 4K) to the TV which does a better job than Kodi on any ARM hardware device. Almost nobody needs 4K60 modes as very little content exists in that format, so there's no real-world need to force that in config.txt (hence it is not our default). In some cases the best option is to revert Kodi to defaults again and resist the urge to fiddle with things that don't really need fiddling with 
I have Kodi set to 1080@60 desktop with 1080p 23.976/24/50/59.94/60 and 4K 23.976/24/25/29.97/30 modes whitelisted, adjust refresh enabled, and everything else video related on defaults (so deinterlace is auto) and audio on a 5.1 pcm config. Kodi outputs progressive always, so if you are working with deinterlaced content it's important to exclude the 25Hz mode as Kodi needs 50Hz to render 25x2 interlaced frames.
NB: I don't really know how TVH is configured because someone else (one of the Kodi developers, who is Finnish) runs that bit. He aggregates DVB-S and DVB-T connections. I only use it for DVB testing in LE and watching the occasional F1 race but AFAIK the TVH bit is left more or less default. I see some artefacts and judders in the streams from time to time, but my client device(s) are 4,500Km from the server and I route everthing thruogh a VPN to the UK so I have fairly low expectations on performance.
LE defaults to using HDMI output for audio/video on Pi Hardware. RPi3B+ will use MMAL decoding (only RPi0/1 should use OMX).
This forum does not discuss or provide Android firmware, please use freaktab or similar.
It looks like the rtl8188ee driver in the kernel is pci only, not usb, so nothing is showing up. This means you'd need the realtek vendor (not in kernel and breaks on every kernel update) driver .. and we've a long history of refusing to add them because they're a pain in the rear to maintain over time.
Put LibreELEC-AMLGX.arm-9.80.0.tar in /storage/.update/ and reboot, then run "dmesg | paste" and share the URL after it's rebooted (no need to copy/paste to pastebin). The image has a newer kernel with more realtek drivers enabled - and we can see if the card is detected. NB: If it is the card probably won't work due to missing firmware, but the log should should which firmware.
You can experiment with the AMLGX test images on https://test.libreleec.tv using a different SD card, but you will need to experiment with device-trees (Tanix TX3 is another S905W device and might work) but the images are still not ready for prime-time use yet so it would probably be better to stick with the current image and use OpenVPN.
There is some progress on HD audio (not specifically about Atmos) but things are still not at the stage where things should go into public images for general consumption. And video things still have priority over audio.
The 4K@50/59.94/60 modes will not appear unless you force "hdmi_enable_4kp60=1" in config.txt, but since the GUI runs best at 1080@60 (as the TV will upscale 720/1080p skins to 4K better than Kodi can) and 99% of 4K media is [email protected] .. is there any actual reason to enable it? As a rule the answer is no, which is why this is not a default option.
WireGuard support is still new and somewhat experimental and there are some systemd changes being figured out (slowly) in another forum thread to ensure more reliable connectivity. The issue of DNS leaking in known but also not something that will be simple to solve. The issue is that connman will append DNS servers specified in the wireguard config file to /etc/resolve.conf but it will not remove the existing nameserver at the same time because connman does not "manage" the DNS servers. As a result, traffic will route through the tunnel, but DNS will still resolve through the local nameserver as this is still the primary (first listed) nameserver. Resolving [sic] this probably requires a switch to using networkd (part of systemd) which is a non-trivial change for the distro to make, and isn't likely to be done anytime soon. The next-best thing is to write a handler script to remove (and cache) and then restore (from cache) the DNS servers, but there are multiple ways to change network properties while a wireguard tunnel is up, which might alter the list of nameservers, so it's one of those things that sounds simple but is programatically complex with a load of caveats on realiblity. More serious investigation on the changes needed to eliminate DNS leaking are not on my personal to-do list right now; because WireGuard works reliably for me, I don't have much time due to a busy work schedule, and the DNS leak is not important for the personal use-case that I implemented WireGuard support for. Sorry if that sounds rather "not interested" but .. I don't have the time to deal with it so the community at large will need to contribute to solving it.