There is no mirror redirection for add-ons, and these days we don't block any IP/CIDR ranges either, so if the device cannot connect to the repo the issue is likely something on your end.
FWIW, I have no issues downloading add-ons on an RPi5 here, and RPi4/5 use the ARMv8 add-on repo so that's correct.
Have you tried force-refreshing the repo in Kodi?
In the absence of any technical detail (debug logs and such) .. no idea what the issue is 
In crypto things IKE is normally an acronym for "Initial Key Exchange" but no idea if this is correct here.
NB: If Yemen is anything like the UAE, you need to visit the local computer souq and find the guy that specialises in satellite things, and they will know how to set-up the right software/hardware to make things work (insh'allah). In this forum you'll only find people that understand how to make things work in the EU and maybe US, but not Middle-East countries.
I can clear the emmc using the following command LibreELEC:/ # emmctool zero. After which I can boot using the "wetek-play2" image installed on a second SD-Card using the LibreElec USB-SD creator. Right?
Correct.
I'll fix the missing 'b' for backup in the next update to Amlogic or Rockchip that I push to master.
There is no known Kodi SMB client bug in K22/LE13 images. Have you bothered to experiment with the protocol version as asked?
You cannot boot the "wetek-play2" image from SD card without first erasing emmc (use emmctool from the box image) because if vendor u-boot exists on emmc the box always boots it and not mainline u-boot from the SD card. The boot partition on the SD card contains only extlinux.conf for mainline u-boot and this is not seen/understood by vendor u-boot; hence it cannot find legacy boot files. You can of course copy s905_autoscript etc. over from the box image but this replicates booting the box image from vendor u-boot which doesn't proove the issue with mainline u-boot is resolved.
So, erase emmc to force mainline boot from SD card. If the noise issue is resolved then it should boot. If it is not resolved, it will drop to the u-boot console where you can type 'boot' to continue booting. If you want/need to revert back to vendor u-boot I have a raw disk (dd) backup that can be downloaded and copied to /storage on the SD card and written back using emmctool again.
K22 contains some minor changes to the SMB client:
* Defaults to SMBv2 and large MTU support (not plain SMBv2)
* Defaults to 128k chunk size (and size is configurable)
The defaults were chosen by Kodi devs to work for the majority of people but perhaps your old router needs something different. Go experiment with options and see if that results in working connections again. I'd start with the minimum protocol.
It would be better to post on https://github.com/ampache/ampache/discussions
I might be missing something, but what has this got to do with LibreELEC?
Anything on the UART output? (this is why it's kind of needed for these tests)
When you say things are very-clear on the Free Guy movie; what is the frequency that the dropouts occur? .. because watching that movie I hear only a handful of audio glitches in the 2-hour movie. Again, from the way people have been moaning I'm expecting to hear something every few minutes to create a constant annoyance but that's not what I'm experiencing. To be clear, I do hear some glitches, but I want to ensure I have the same experience as others.
I've acquired a Beelink S13 mini (Alder Lake, N150) box for testing and have this connected to a Marantz AVR with 7.1 pass-through configured. I've been connected to both HDMI ports. I've not seen any video issues, and I've experienced only a couple of brief audio glitches when playing [email protected] + TrueHD media, but it's not happening often and the way folks have been moaning about things in this thread I was expecting something more frequent or obvious. Is the 'dropout' a momentary glitch or silence lasting a few seconds? - and what's the frequency of occurrence?
I'm also interested if someone can share a media file that reliably triggers this issue with good frequency and duration, as my own test media doesn't seem to achieve much.
The HEVC decoder was never really finished so it mostly works, but some media files cause issues and give no output. S912 also has no support for DV so you won't get output unless media contains a normal HDR fallback stream; some does, but most of the content from online streaming sources does not (to save bandwidth). It's also hard to comment on what happened without seeing a debug log. In the current codebase playback is what it is until Amlogic get further along with upstreaming.
Analogue output is likely a little under-developed given the focus on HDMI so no real comment on that. This wiki article should get the remote working: https://wiki.libreelec.tv/configuration/…ration-advanced - the generic q200/q201 device-tree files intentionally don't contain preconfigured keymaps so you need to define your own.
I have a Mecool M8S PRO L with 3GB ram and 100 Mbit lan. Its working with the meson-gxm-q201.dtb file, but I only seem to have 2GB being used by kodi. Any way to update the dtb file?
The upstream kernel doesn't have/need the complication of hardcoded RAM sizes in device-tree; it auto-detects whatever capacity the box has. So either the Amlogic (Android) u-boot code booting the box has been hacked in some way to withhold RAM from the kernel, or the box has 2GB ram and vendor u-boot/kernel code was hacked/hardcoded to show a fake 3GB value. The latter happens quite a bit on Android boxes from the GXM era, so IMHO is the more likely explanation. NB: Kodi runs happily on something with 1GB RAM so 2GB RAM is more than enough unless chasing an exotic configuration with lots of services running in the background.
I've had thoughts about controller compatibility, but that wouldn't explain why something works when connected to a monitor and doesn't work when connected to a TV .. which (other than there being some magic aura around the monitor) honestly makes zero sense to me. I'm out of ideas
There's some simple runtime logic for "if this doesn't exist on /storage, create dirs and copy from SYSTEM" so there's always the option to stash the QQ customisations inside the image and if e.g. /storage/.kodi/addons/skin.custom doesn't exist, unpack and create them without the user ever needing to transfer things over SMB. It would be quite simple to maintain customisations in a GitHub repo and add them to the image with a custom buildsystem package under packages/oem which works the same as the packages/virtual location. Also not complicated to check versions of things on /storage and use the same mechanism to update items statically instead of using an online 'repo' for things. In some ways LE is difficult because it's different. In others (and once you understand the mechanisms) is really rather flexible and simple.
