"errorDisplayMessage": "This title is not available to watch instantly. Please try another title."
That probably means something to the Netflix add-on developer(s). It means nothing to me (see previous comment in post #2). The Netflix add-on support thread is in the Kodi forum, not here.
Your box does not use the Tyr driver so that has nothing to do with it.
I pushed my current working DVB patches branch to https://github.com/chewitt/linux/commits/dvb-7.0.y/
I pushed current AMLGX working image changes to https://github.com/chewitt/LibreELEC.tv/commits/amlogic
To make image packaging easier I have the Linux patchset I'm testing in projects/Amlogic/patches/linux and a separate set of DVB patches in packages/linux/patches/dvb as this makes it simple to regenerate each patchset independently (using a script) and then I can respin the image to test changes. Thanks to an ex-employer that went bust I'm lucky to have a 32x core build server so image respin time (only rebuilding the kernel) is around 2 mins; then I pull the image from the server to the current test device over scp and reboot to see what broke/changed/etc. and then give feedback to Claude. NB: If you ever wondered why I always hardcode a static version in all my test images; it means I can predict filenames on a remote server to make transfers easier.
Kodi does not ship binary add-ons for Linux because there's are too many different distros; so it's the responsibility of each distro that ships Kodi to also build and package the accompanying add-ons.
Hence LE has its own repo!
I can see 'stars' in our Generic Legacy repo: https://addons.libreelec.tv/12.2.0/Generic…eensaver.stars/
I cannot see it in Generic (non-Legacy) repo so perhaps it depends on X11 (only available in Legacy).
Ahh, rozpruwacz is Marek 
I now have the DVB-S and DVB-T tuners for the WeTek Play2 and the DVB-T tuner in the O2.cz box showing up in Tvheadend. I am able to run a scan without errors. However I have no Satellite dish or Terrestrial antenna to connect them to so all scans find zero services (as expected) so it's impossible to tell whether anything is really working 
I've pushed an updated set of images to my testing share. The WP2 image and 'box' image will boot the default WP2 device-tree which contains no DVB support, so you will need to edit extlinux.conf or uEnv.ini and change the dtb name to one of:
The O2.cz box (SML-5442TW) and the GTMEDIA GTT-2 box Marek has been using both have DVB support enabled.
Once WP2 is rebooted with the correct device-tree file dmesg should show the cards, and you can install Tvheadend43 (or VDR) to scan for services. I'm a bit vague on the remaining process as (as mentioned) I can't test anything.
rawnar I've also included a WeTek Hub image in the test share. Apologies for the long wait, I got a bit distracted.
If someone can say for sure though that their x86 install of libreelec 12.2.1 is working correctly with widevine L1 then it's prob just my setup specifically being borked
Widevine L1 requires a TEE (Trusted Execution Environment) and device-specific certification. The only hardware I'm aware of that supports this are ChromeOS devices; when running ChromeOS (not Linux). All other devices will be limited to L3 which restricts you to 720p or 1080p, depending on the service. The same is true for ARM SoC hardware; the device needs to support OP-TEE and the video pipeline needs to support interacting with secureworld. Although it is possible for L1 certification on ARM SoC hardware under Linux, it's rare and requires a hardware-specific distro, e.g. OSMC for their Vero devices. L1 is mostly only found on Android devices.
TL/DR: L1 is not supported on x86_64, only L3.
You'll need to create a debug image and use valgrind to understand more. Top doesn't show anything useful.
taki Interesting! .. but I would ask that you push current working code to a GitHub repo as it would make a lot of sense for Marek (and likely others) to collaborate on a clean demux rewrite that could eventually be upstreamed, than get too far down the road of reworking vendor code.
NB: I have been poking around in the vdec code recently and have one MPEG2 video that now decodes (badly) which I guess is an improvement on no videos decoding. I have a hunch the underlying issue is about alignment of buffers to frame dimensions, but neither I or Claude managed to spot the problem yet. It continues to be something I tinker with (among many things) though.
kodi.bin .. which isn't granular enough information to be useful .. and I will end up relying on others to hunt that kind of issue down as that kind of debugging isn't something I know how to do
The RPi5 image in my test share seems to work, although I also suspect there is a memleak somewhere so YMMV.
I see nVidia and Waipu and VPN and summise that whatever the issue is, I'm not the person to investigate it.
Using some initial work from https://github.com/mczerski - Claude and I (mostly Claude) have made some progress on mainline DVB support: https://paste.libreelec.tv/moving-lab.log .. the above is from a WeTek Play2 box.
Before anyone gets wildly excited, the vendor kernel demux driver that Marek started porting is a festering ifdef nightmare that looks like it needs a lot of work and I have no way to test DVB-C, DVB-T, or DVB-S things; so I have no clue if the now-showing-up adapters do more than look pretty. Marek appears to have more of a clue about DVB things than me so cross fingers
NB: I plan to dig out the DVB-S module for WP2 and an old O2.cz box that I have in a cupboard somewhere and get those working next. Once that's done I'll clean up the smorgasbord of patches, push branches to GitHub, and share some updated images.
Pairing and Trust are separate actions; IIRC both are needed
CE (and old vendor kernel LE images) can boot between SD/eMMC in the GUI because the Amlogic u-boot environment where boot preferences are stored is accessible from Linux (via proprietary Amlogic drivers). There is no equivalent mechanism with mainline u-boot and Linux. NB: CE issues belong in the CE forum, we have no experience with it here.
I was checking whether it was a phone app remote as we suspect a leak via JSONRPC, but no.
Memory leaks are always a bitch to find unless the impacted end-user happens to be a software developer with some experience of using debugging and analysis tools. I am also seeing a leak (or leaks) but given the differences between your LE12 and my heavily patched LE13 version of Kodi, it's unlikely to be the same root cause.
YouTube will never be simple to install because Google charges for API based searches. The add-on embeds pre-configured API keys but these have a limited free search quota per 24h period and Kodi has a large userbase so the quota is exhausted within minutes of resetting. The cost of providing paid-for 'free' search for Kodi users would require considerably more revenue than the income Kodi generates from t-shirt sales and public donations. Kodi also has an open-source add-on ecosystem so if we funded API keys in the YouTube add-on, they are not secure and will be instantly stolen and reused by other apps and services (this already happens with the pre-configured ones) with their quota consumption charged to Kodi. If you want easier Google services, the only realistic option is to use the native apps on Android, as then Google provides free access to its own services because "If the service is free, You're the product" is one of the foundation principles of their business model.
For BT problems; delete the device and then redo pairing and (separate) trust using bluetoothctl from the CLI over SSH and see if that then works better. Headphones normally need pair/trust relationships.
If multiple phone apps aren't working, perhaps:
You're posting your unnecessarily bolded text in the wrong forum. Our interest and [limited] expertise in Rockchip hardware is focussed on mainline/upstream codebases, not downstream vendor garbage, and we don't use Yocto/OE, and we loathe hiding things behind secureworld.
--- a/projects/Generic/linux/linux.x86_64.conf
+++ b/projects/Generic/linux/linux.x86_64.conf
@@ -2442,7 +2442,11 @@ CONFIG_SKY2=y
# CONFIG_SKY2_DEBUG is not set
# CONFIG_OCTEON_EP is not set
# CONFIG_OCTEON_EP_VF is not set
-# CONFIG_NET_VENDOR_MELLANOX is not set
+CONFIG_NET_VENDOR_MELLANOX=y
+CONFIG_MLX4_EN=m
+# CONFIG_MLX5_CORE is not set
+# CONFIG_MLXSW_CORE is not set
+# CONFIG_MLXFW is not set
# CONFIG_NET_VENDOR_META is not set
# CONFIG_NET_VENDOR_MICREL is not set
CONFIG_NET_VENDOR_MICROCHIP=yModules need to be baked into the image. Something like that ^ should enable CX311 support.
As a general rule we are okay to enable modules by default , but will want to:
In short, user does the research on what's needed, then we can take it over in the long term. We are likely to refuse niche hardware requests if the modules and/or firmware are large in size; we care deeply about being a minimal distro and this is not maintained by adding driver/firmware bloat that only a single handful of users might ever use.
It's not hard to maintain a self-built image. As long as it works, there's no obligation to update and rebuild frequently.