See https://github.com/LibreELEC/LibreELEC.tv/pull/9587
You can replicate this locally by creating /storage/.config/udev.rules.d/98-eventlircd.rules with the same content as the PR.
I'm interested in testing/feedback a) to get this merged for LE13, b) potentially to backport for LE12.2.
The patch was merged in Kodi master branch (Piers) but hasn't been backported, so it won't be in the Kodi 21.2 release which I'm expecting to be tagged tonight with an LE 12.2 release to follow-on sometime in the next week.
LE13 nightlies are here: https://test.libreelec.tv/13.0/ (scroll down for latest files). I won't ever promise a nightly is stable, but at this point it's an accurate term. I've personally been running them for a long time.
Could you please help here with specific commands?
https://wiki.libreelec.tv/configuration/wireguard#known-issues
Pirates aren't welcome in this forum.
It's a long-running issue that impacts a small number of users. It is not RPi hardware specific. Things that may help:
It is probably an issue with iwd (as reverting to wpa_supplicant works around it) but it remains unresolved largely because nobody who can replicate the issue has code-level fault finding skills, and nobody among project staff or regular technical contributors with such skills can replicate the problem.
This is resolved now.
will there be a Kodi 21.2 built with the newer kernels and a Inter ARC bug fixes ?
No, LE12 uses Liinux 6.6 for most hardware. There are LE13 nightlies with newer kernels and newer Kodi too; and while I won't ever promise a pre-release version to ne 'stable' it's an accurate description right now.
In the "PC" world vendors expect users to use a monitor and control the screen with a mouse/keyboard, so nobody adds the CEC chip as it's extra cost. In the "ARM" (SoC) world everyone expects the box/board to be connected to a TV so 95% of devices include CEC functionality. In short .. 
Any chance we can get this feature implemented/merged?
If it gets merged into upstream Kodi we will have the feature. That won't happen though, because it's a hack, albeit a clever one.
Yup, so take the 4-8GB backup tar file, clean install the new device, restore the 4-8GB backup from the tar file. You'll be done 12-18 hours faster than block cloning a 128GB SD card. Users constantly obsess about cloning, but you don't need an identical card, you only need one with the same data on it, and that's the easiest/fastest route to that objective.
NB: As you discovered, most cards do not have exactly 100% the same 'disk' geometry which complicates block cloning.
Use connmanctl to review and perhaps change the interface sequence order to modify routing.
While 98% of the boxes out there have the same Broadcom RTL8211F chip inside, there are occasionally other chips used, and they can be using a different bus slot which requires a different device-tree and/or maybe an additional driver in the image. As a start, share the system log (assuming you can access SSH over WiFi).
The wiki is open to public contributions.
The solution is to back the contents of the card and not clone (at block level) the entire card. This will also be massively quicker as you're usually backing up no more than 4-8GB of Kodi data, unless there are media files on the card, rather than the entire 128GB card. Learn to use tar.
I've pushed an updated set of images to my test share with:
I'm interested in any reports of HDMI sync loss when playing media (along with mediainfo details) as the fix for YUV420 @ 59.94 fiddles with HDMI clock plumbing.
I'm also interested to hear if WeTek Hub boards are booting fine now? - some folks had an issue we suspected of being noise on the UART that caused it to see a keypress and enter the u-boot console instead of booting. Feedback would be nice.
WireGuard requires the host (server) to be an IP address and ConnMan does not implement logic to resolve an FQDN to an IP before configuring the WireGuard interface and bringing it up, or perform periodic validation of an FQDN to detect IP changes.
It's not an impossible problem to resolve [sic]. Create a script that resolves the FQDN against a trusted upstream DNS server (not a local one which caches results) and compares the IP to the current WireGuard conf IP, and if different, sed the value in the conf and then restart the WireGuard service to recreate the connection with new values. Use cron or a systemd timer (which is cron) to run the script at periodic intervals.
I made an effort about 2-years back to clean-up the Linux 3.14 era drivers so they compiled against a modern kernel. These can be found here: https://github.com/chewitt/linux/commits/dvb-sucks and I rebased them against Linux 6.12.y only last week. However there's no Amlogic demux driver in the upstream kernel (which is essential) and we need tuner/demod drivers to be independent rather than interdependent so we can describe a box configuration in device-tree rather than compiling everything into a single monolithic driver as the Amlogic vendor kernel does. The monolithic approach works for box manufacturers who need to support a single box with a single driver recipe, but doesn't work or scale when you need to support a range of devices; each with a different tuner/demod/demux driver combo.
It's not a huge amount of work to get done, but it takes a certain skillset and mindset to hande the code archaeology and writing of modern kernel drivers. It's already been 'years' and nobody volunteered, so I have low expectations of it ever happening.
The 12.0.1 release notes that nobody reads describes some "no" items for the AMLGX image:
The latest and last release that might support them is LE 9.0.1 although dtech has an LE 9.2.8 image that might also contain them (but I don't track it, so no guarantees). The upstream kernel in LE 12/13 has reasonable support for USB tuners.
