"Hi10P H264" ~35%
^ 10-bit H264 is not an official standard so although it's widely used by anime fans there is no hardware decode support for it on any ARM device that I have come accross. Most anime fans gravitate towards an Intel NUC with a CPU capable of decoding the content in software.
sudo dd if=LibreELEC-RPi4.arm.img of=/dev/diskX bs=1m^ the low-tech method for macOS and Linux
I need to blow the dust off the VM that I have used to replicate building the creator app and if I can persuade someone with a clue about macOS and Qt development to poke the code. I can't promise a quick fix 
The difference between self-building a full image and a driver add-on package is quite negligible, and IMHO the packaging with a standard package is lots easier to comprehend if you're not so familiary with the build-system. Create another driver under packages/linux-drivers and then add the new package name to the list of drivers in distributions/LibreELEC/options .. then "PROJECT=Generic ARCH=x86_64 make image" should build everything with the driver baked in. Just make sure you fork a new branch in git to contain your changes (don't hack in the release branch) and then it's trivial to rebase your changes and rebuild whenever we push changes to the release branch (new release etc.).
I'm fairly sure there's no restriction on card size for the USB/SD app, but I'm wondering if firmware supports cards that large. I've asked one of the Pi Foundation folks if there's a restriction, but if you have a smaller SD card kicking around, perhaps do a sanity test with it.
I remembered that Kodi supports configuration of smbclient through /storage/.kodi/.smb/user.conf .. if the file exists and containts Samba (client) config settings at startup they will be included in the configuration used. Do some reading of Samba documentation to see if there are any client options that can be set to follow symlinks/aliases? And again .. you might want to explore mounting from systemd instead of Kodi.
It's hard to guess without seeing what the error is. Plan B .. clean install the second machine and get it on the network, enable ssh on both, and then use scp to recursively copy content between the boxes.
echo "options cfg80211 ieee80211_regdom=DE” > /storage/.config/modprobe.d/cfg80211.conf^ swap "DE" for UK, FR, RU, etc. as required, and see if that makes a difference.
LE does not use nouveau. If you can boot a normal Linux distro and find the pci bus device IDs we can cross-check against nvidia drivers.
If you share the logs we asked for and we can see what's going on. If you don't share the logs and all we can do is guess.
I can see two issues:
a) The repository.unofficial.addon.pro reference is old cruft from an OpenELEC installation. The domain expired or is no longer available; and the add-ons there wouldn't be compatible with LE releases anyway (maybe v7.0 but not v9.2). This can/should be uninstalled.
b) The version of LE appears to be v9.1.x (pre-release) not v9.2 (release). I'd be inclined to start over with a new install (update to v9.2 and then rename /storage/.kodi to /storage/.kodi-old and reboot) and then only copy back things from the older install which are really essential. As a minimum you need to update and then the correct add-ons should be used.
There is no package manager in LE and we refuse to add more garbage realtek vendor binary drivers to the core distro as they break with every kernel bump and require onerous maintenance. There are several examples of people sumbitting (and us refusing) realtek drivers in our github repo - have a look at closed pull requests. Similar packages with sources obtained from somewhere might work. Or might not .. that's the problem with out-of-tree drivers. If you abandon the idea .. have a look for devices with a railink chip as these a generally supported in-kernel. Or get a wireless bridge that connects via Ethernet. They're often cheaper and give better range/reception than most USB cards.
I forget whether TVH supports TLS by default, but if not you can probably reverse proxy the connection from nginx which easly supports letsencyrpt and then all client/server comms runs through a encrypted tunnel.
Port knocking sounds wonderful until you try and find client apps that support it .. be prepared for a long wait.
Best place to ask will be the Plex forums, as Plex maintains the add-on in the Kodi repo.
Kodi uses Samba smbclient to mount SMB shares and this will not follow Windows aliases and maybe NTFS junction things (never heard of them). The only other thing you can try is mounting shares via systemd (see /storage/.config/system.d/) and then having Kodi access the now-local drive. I have no idea if the kernel SMB capabilities support following junction links or not .. you have to experiment.
LE packages Kodi to use ffmpeg libraries so there is no ffmpeg binary in the default OS image. We also package a normal binary version of ffmpeg in the ffmpeg-tools add-on. This is compiled with more options enabled to make it more suitable for use with other apps.
Use a decent router with a proper firewall (maybe even threat protection built-in) to protect the TVH server behind it, and port-map from non-standard ports on the router WAN IP (obscurity not security, but avoids some probing) to the standard ports on the TVH server. I wouldn't bother with VPN as TVH provides access to public broadcast video streams not personal data.
KVIM is a legacy image for VIM1 only. The add-on errors are likely caused by the Python2 to Python3 change in Kodi v19 - you'll probably need to remove all add-ons and reinstall them with K19 compatible versions. Once an add-on is reinstalled you can probably copy the config back to preserve settings. The fun thing is .. not all add-ons will be available in Python3 versions yet.