Two suggestions:
a) locally mount the remote filesystem(s) via systemd mount files. This allows you to place a hard dependency on the local mount completing before the Kodi systemd target can start.
b) manually update the library periodically after you add new content, not automatically on every boot.
Also remove /storage/.kodi/addons/packages .. as the add-on filenames don't include aarch64/arm and Kodi will reinstall from the cache (of aarch64 binaries) if the repo and local add-on versions match.
MikeKL you will need to uninstall any aarch64 binary add-ons from the LE repo and then reinstall arm versions. As long as you keep the config data when uninstalling (Kodi will prompt to remove it or not) it's a simple and quick process.
Please check options with whoever creates the image you're using. It's not an official one..
I'm not sure if /storage/.config/asound.conf still works as an override, but it used to (admittedly a long time ago, so no guarantees it still does).
Index of / has nightly images from Jenkins.
TVH is running on a dedicated port (9981) which is being proxied so there's no need to change the root path.
Passthrough will be supported, but (again) what can be passed-through will depend on what the hardware supports running under Linux.
Not supported.
ir-keytable needs to be listening on the right protocol to see anything and some remotes have odd vendor invented stuff for power-on events; for the same reason you might not be able to teach a remote that only understands specific protocols and doesn't just capture/record whatever signal is transmitted to it. I'm about to start playing around with the current official HK remote to ensure it works on mainline kernel images using mainline u-boot, but that's not an endorsement and might not be a quick solution.
The connection manager (connman) stores static connection details against the MAC address, and if you investigate you'll probably discover that the kernel is assigning a random MAC address on each reboot, so there is no matching profile and it defaults to DHCP again. The cause is the hardware manufacturer being too cheap to spend some $$ getting a block of unique MAC addresses for their hardware. To advise a workaround we'll need to know what hardware you have?
Users often and wrongly believe pass-through is some magic "hardware doesn't touch the bitstream" method, but in reality the hardware has to support the stream format to correctly detect and handle it as a pass-through stream. Raspberry Pi doesn't support any HD formats.
Good point 
Add "textmode" to kernel boot params in uEnv.ini and connect a USB keyboard. You'll boot to a console where you can run commands. After running them, remove textmode again, then reboot.
chewitt, now, when using the mainline kernel, everything is the same at the linux packages level between Allwinner and Amlogic. With one exception, the m2m cedrus and meson implementation are not compatible. Is there some standardization / merge in progress on that matter?
The video pipelines for Amlogic, Raspberry Pi and Exynos have stateful decoders while Allwinner and Rockchip have stateless decoders. It's not possible to combine them into a single m2m implementation as stateful/stateless work in fundamentally different ways, although we are working to minimise the differences and have ffmpeg mask the implementations so there's still a single/common interface with Kodi. As there's no prior art for anything it's a "two steps forwards, one step backwards" kind of process, and there's still a ton of code to write, but the direction is still forwards, and each month ever more bits of the big jigsaw puzzle are falling into alignment.
You'll get the DTS core of HD formats on Raspberry Pi, but that's all.
Yes, within the limits of the audio formats that Raspberry Pi supports.
How you burn the image (USB/SD Creator or Etcher) has nothing to do with how the image runs. If it boots, it boots.
Try running "systemctl stop [email protected] && systemctl disable [email protected]" and reboot.
