^ Network tools not System tools.
NB: For any future requests, the contents of the various tools packages are included in the package descriptions in the repo so you can check what's inside without needing to ask in the forum.
You need to ask in the YouTube add-on support thread in Kodi forums. I've no idea if there's a current solution to the problem but it has nothing to do with LE and everything to do with Google being a grade A1+ pain in the rear and moving the goalposts around on what's needed to evade their API usage rules and desire to ruin their user-experience with an unholy amount of adverts. In short, the old solution is no longer the solution. FWIW, I see the same but haven't worked up the enthusiasm to hunt down the solution just yet.
H264 has lots of variations and the H264 codec in the Amlogic vendor kernel that CE uses handles more of the non-standard ones than the RPi4 codec. Two common examples are 4K H264 (RPi4 handles 1080p max) and 10-bit H264 (not a broadcast standard, RPi4 doesn't support it at all). RPi5 sort of solves the RPi4 issue by having no H264 hardware codec at all so ffmpeg falls back to software decode which allows a wider range of media to be played; at the expense of needing more CPU (and RPi5 generally has enough).
NB: To confirm the theory ^ you'll need to share Kodi debug logs and/or media samples.
If you start to poke around in the Gitlab issue log for the Intel DRM driver you'll see reports and triage that reveal the problem isn't simple like LSPCON vs. no-LSPCON; as there are different LSPCON chips (different chip vendors) with different properties, and even identical LSPCON chips can have rather different implementations (different electrical properties, resulting in different bandwidths available on internal connections) on different boards. In some cases firmware changes can tweak voltages and such that drive the LSPCON chip differently so achieve improvements. In other cases the LSPCON implementation is more fundamentally wrong and no tweaking can get the right result. Most of the issue reports are focused on graphics performance; but the underlying issue is related to bandwidth and thus HBR audio (needing more bandwidth) suffers similarly to higher resolution and refresh rate and colour depth graphics (needing more bandwidth). TL/DR; 
The Docker add-on exists in the LE repo but you might need to force refresh it before LE12 add-ons are available.
It should work with the Generic Legacy (X11) image. It will not work with the non-Legacy (GBM) image.
I can see there are wlan0 and wlan1 interfaces now. Disable onboard WiFi by adding "dtoverlay=disable-wifi" to config.txt on the SD card and then see if you can configure a network.
Oleg stopped work on Amlogic boards some time ago and deleted old files.
If you are running dtech releases for M8X2 this is already the latest/last available version, there is nothing newer.
The USB device ID's aren't present in the downstream driver we are still using (sadly).
Update to this image and see if it works: https://chewitt.libreelec.tv/testing/LibreE…h64-11.95.2.tar
Run "journalctl | paste" after boot and share the URL
I've no idea if NTP is the cause here, but I would leave nothing set so the OS defaults to pool.ntp.org servers. There's really no need to set custom NTP servers unless ntp.org is blocked for some reason.
It's possible to change latency for video content (to align with audio) but I think that mechanism assumes Kodi is playing both and that won't be the case with an audio-only stream being played.
NB: At one point it was possible to 'cast' YouTube URLs from a smartphone to Kodi so they played (audio and video) on Kodi; which would be played together (in-sync) and somewhat avoid the problems.
You are running the latest available LE release for Meson 8 hardware. There is a long-term effort to add support for Meson 8 devices into the upstream kernel (which would permit Docker support) but this is a rather slow burning effort and there's no timeline for an LE release.
Not supported because the 3.10 kernel is too old to support Docker.
Here's a quick update on the "xz" issues that are being widely reported at the moment (CVE-2024-3094).
- LE12-beta1 and LE12 nightly images since January 27 2024 contain problem xz versions (5.6.0 and 5.6.1)
- We have already reverted to an older non-problem version (5.4.6) in our master branch
- We are investigating complete removal of xz binaries (reverting to xz from busybox)
- We have tested the LE12-beta1 release using exploit signatures. These show WE ARE NOT VULNERABLE.
Staff are working on a beta2 release and this will ship soon, but as we are not vulnerable we are not going to rush the release. If the situation changes due to new information we will (re)evaluate our response and adapt as necessary.
Please go back to enjoying your weekend 
I will have a chat with chewitt and ascertain what hardware he has and what to send him and see what is available. I know that he was responsible for upstreaming DTS support for Vero 4K + to the kernel.
I don't have any Vero boxes in my collection. Existing support for 4K+ (upstream) and 4K (not-yet-upstream) was developed through educated guesswork from me and testing from frakkin64
Older Apple hardware often pays lip-service to EFI specs and might refuse to work with syslinux. Unless you fancy experimenting with tools like "rEFInd" (a great tool but sometimes hard to understand) the easiest option will be to experiment with a recent Ubuntu LiveUSB to see if that boots. If it does; the version of grub Ubuntu is using on the LiveUSB can can be installed to our boot USB (replacing/overwriting syslinux). You may need to create grub boot config/menu files.
Two further comments:
a) Laptops are not and never have been target hardware for LE, and Apple laptops full of quirks are no exception.
b) LE isn't going to magically add capabilities or performance improvements over the native macOS Kodi app.
rm -rf /storage/.kodi/addons/inputstream.*
rm -rf /storage/.kodi/addons/packages/inputstream.*
rm -rf /storage/.kodi/cdmM-Reimer Those commands ^ should remove all traces of inputstream and related widevine files. You should be able to reinstall inputstream add-ons from the LE repo and then let the widevine files be downloaded/unpacked again.
Also note that we have a virtual image (OVA) that runs in vmware Workstation/Fusion or Oracle VirtualBox; which can make running LE on something fast(er) and more local/portable easier than using a real board/box device.