Could it be possible that the latest User Agent from the Libreelec Version ist not known by the addon repository?
It's because balbes150 persists in creating "aarch64" images and the image is probably still configured to point at the "amlgx" repo that I maintain which only contains "arm" addons. No bug, and I have no intention of building aarch64 stuff 
On update the old version may be flagged as incompatible, but the first time the LE repo is contacted it will (or should) detect and update to a newer version which should be compatible. It's definitely in our repo at latest version.
Any further investigation requires a Kodi debug log to be shared.
Have a look at the "Pi Tools" addon; it most likely has all the extra Python libs/bits required for GPIO work etc, and if it doesn't we'd be happy to accept changes to add them.
Connman's hotspot feature is the equivalent of a mobile phone hotspot (which is exactly what it was designed for) and has similar levels of simple on/off configurability. It is not designed to be an access point replacement and there is zero intent or interest among it's developers to evolve it into something more complex. You can change the SSID name and passphrase in LE settings. It doesn't mess anything up (at least, not in LE). LE does not build connman with the DNS proxy feature. OSMC does build with it.
LE is an embedded distro so you cannot update packages using a package manager (as there isn't one). If you want that kind of shizzle you need to stick to a more conventional distro (OSMC, Armbian, etc.). Current LE alpha releases use connman 1.36 which is the latest release.
Amlogic have started to upstream support for their next-gen S905X2/D2/Y2 and S922 platforms into the mainline kernel but it's a drip feed of commits and I doubt the reference boards I have will be usable for some time. The DRM driver will also need some rework (which depends on funded goodwill from somewhere). Other IP like the video decoder shouldn't require much effort and the audio architecture is common to the AXG audio platform which already has excellent upstream support (so little work required there). The GPU core is also easy as the driver packaging will reuse some of my recent experimental work and we lobbied Amlogic to license mali blobs this time around so there's no repeat of the S912 mali fiasco.
So next-gen devices will initially depend on the Amlogic 4.9 buildroot kernel and amcodec. The 4.9 kernel is an evolution of the mucking fess 3.14 kernel; only it's been further hacked around Android specific requirements and there's really nobody anywhere poking fingers at it right now since all currently available hardware is supported on 3.14. It can probably be made to function with Kodi on Linux but you can expect a new generation of badly coded bugs to be present, and it's era will ultimately be shortlived as amcodec is due for removal between K18 and K19 (and Kodi devs are not intending to have such a huge gap between the K18 and K19 releases). Next-gen devices are probably best left on Android until mainline kernel support matures.
For extra fun there is a general drive among box manufacturers towards the AndroidTV codebase instead of AOSP and in theory this means next-gen devices with locked boot configs. There will be AOSP devices that can be used (hopefully some nice board devices) and the list will be shorter than people are used to, but less confusing choice isn't a bad thing.
On the positive for S912 users; panfrost has now rendered the Kodi home screen for the first time (see pic above) although we're still a long way from something usable. Progress is still progress though
In the last couple of weeks i've been sporadically poking 4.18/4.19 kernels with a VIM2 board which uses the RTL8211F chip and experienced awful ethernet performance (major packet loss etc.) until the CONFIG_REALTEK_PHY was switched from =m to =y .. before the change the PHY was showing up as the CONFIG_GENERIC_PHY device, and since it's been fine.
It's probably unrelated, but it jogged my memory of your problem so I figured I'd post something.
LE uses connman to provide the tethered hotspot. Apart from clarifying that all I can see lots of talk about IPs and a/b/c that doesn't make any sense and doesn't actually ask a question; thus I cannot provide any more answers.
MPEG-4 is a container format so I'd guess the video is encoded with an unsupported bit-depth like 10-bit H.264 (the H.264 standard and thus all hardware built to follow the standard specifies 8-bit content) and it falls back to software decode.
mediainfo for the file or a Kodi debug log during playback will confirm the hunch.
It doesn't matter how cheap or expensive the laptop is; crap firmware is crap firmware.
LE 8.2.5 (K17) or any LE K18 image supports SMB 1-3 (our devs added it to Kodi). There is no reason to reactivate SMB1, but you must accept the reality of needing to use authentication to shares on Windows hosts. Once people get over that and stop trying to find a lazy shortcut that doesn't exist anymore; it all works.
Feel free to ask for a wiki account and update the page
To further DaVu point. Kodi reviewers do not expect anyone to submit something perfect first time. The review process is normal and submitting something "known bad" simply to get comprehensive feedback on the items that need fixing is perfectly okay (as long as that's clear up-front).
^ took me 5 mins to create from the logo image in GitHub, feel free to use it.
LE builds Kodi with libdvdcss support. We are generally against piracy, but in the context of current trends the ripping of personal DVDs is a good thing even if your local laws are backwards enough to disapprove.
If you want the OS to display Japanese text in the Console you need to install "locale" from our addon repo. If you want to change the keyboard layout; this is done in the LE settings addon and the options available are dictated by the graphics stack (as I said in the other thread). Xorg has an extensive list of layout options but the Raspberry Pi has more limited options because we are running directly on the framebuffer, we are not using Xorg like Raspbian. Finally you have the on-screen GUI keyboard and Skin language options in Kodi settings.
There's no way to discover this without adding additional debug code into Kodi and the Linux kernel, i.e. add printk statements in code, it's not possible to enable some extra debug logging setting. It's a shame the LG panel doesn't show more info (as I have the 65" B7).
Zeroconf browsing works fine as long as the SMB shares are advertised via Avahi, which normally implies a NAS using Samba. Windows does not ship with an Avahi/Zeroconf service so Windows hosted shares will not be visible over Zeroconf.
Another alternative would be to install portainer via the LinuxServer.io repo (their repo installer is in our repo) as this is wrapped as a Kodi addon and so depends on Kodi; so it won't be started until after Kodi starts, and any containers that it manages are started after portainer.
