It's worth taking a backup, resetting, then unpack the backup and only restore the minimum userdata items like sources/passwords and add-on settings data; everything else should be clean installed. Don't just restore the backup, as if the issue is something gone bad, you'll end up restoring it and negating the clean reset.
I'm fairly confident it's something local to your install or environment. If the add-on was generally broken we'd see complaints from more users, and we're not.
Urgh, I was hoping for a nice kernel splat with lots of information. The log is, err, not so helpful.
Judging by the reguarly changing list of garbage search terms my kids are using the YouTube add-on daily without issues (and it works here for me in random tests/checks) so the add-on is 'working' generally. The latest LE12 nightly has an updated cacert.pem file in the last week or so, but this is unlikely to be the cause or fix of your problem as changes in root certs are rare and coordinated to avoid large scale internet breakage. There are technical reasons (the use of CDN infrastructure) which mean the certs that Google infrastructure presents to you will be different to the ones presented to me, but Google generally does a reasonable job of ensuring its services work so that's unlikely to be the cause either; and breakage on their side is normally temporary not persistent.
Have you deployed a custom cert locally? .. something that would append to the default (embedded) cacert.pem file?
I'm not sure if the limitation is in how Spotify streams audio to the add-on, or how the add-on handles and presents audio to Kodi. The original add-on author is long absent from the forum so the add-on is essentially unmaintained these days; we manage to unbreak it occasionally but if new features and changes are desired, the responsibilty for making them rests with the requestor.
NB: I personally stopped using LibreSpot some time ago as the iPhone app that I normally stream from evolved to support AirPlay and Kodi shows up as an AirPlay target. In this arrangement the current-playing track duration of the media shows correctly. I haven't tried the lyrics add-on (most of what I stream doesn't have lyrics) but since 'time' is correct I think it would work.
After the core dump (assuming the box is still accessible/responsive) run "journalctl | paste" and share the URL generated so we can see what was printed to the system log (usually there is something). Also tell the make/model of the soundbar.
Settings / Player / Language / Preferred subtitle language / None
In laptops of that age the WiFi modules are normally little mini PCIe cards that can be removed, binned, and inexpensively replaced by something using a chipset from a better supported vendor, e.g. some kind of Intel chip that uses the iwlwifi driver.
You're not missing anything. So if it works, don't fix it.
Have a search in the YouTube add-on support thread in the Kodi forum. Most likely Google fiddled with their API's and something needs tweaking in the add-on and there'll be some discussion.
We do consider security issues, and the probabilty of a meaningfull exploit in the wild through LE devices is low. The attacker needs to be in the same network and most LE boxes are hidden behind NAT/firewalls, and if the attacker is already in the local network the HTPC isn't the target of interest and you have bigger things to worry about. In the past I've added some LE devices to instrumented honeypot networks alongside some well prepared deception assets. Most attackers shy away from the devices because they don't fingerprint as something known and recognised. The subset who did try to compromise the LE device generally succeeded with a dictionary attack on the well-known default password not vulnerability exploits, and then they all tried to drop a comprise toolkit into the OS, which fails massively due to our non-standard distro packaging, and they quickly gave up and moved onto other more promising targets in the environment. Plus, even if we rush out a release and push the update to the small percentage of devices that would receive it, the other 90% of our rather sizeable userbase will remain on something older with even more vulnerabilities. In the grand scheme of things and compared to the shenanigans that I see in my DFIR day-job, this is nothing to lose sleep over.
You need to add the drive path as a source, then set content type and scrape the source (and hope media is structured and named correctly for scraping). I personally do that by editing /storage/.kodi/userdata/source.xml as it's easy to crib the format and miles easier using a real keyboard than o-n-e-l-e-t-t-e-r-a-t-a-t-i-m-e with the on-screen virtual one.
There are some Lakka devs in team chat, so I'll ask if they're doing anything different.
The wl driver is only used with a small handful of really old Broadcom SDIO chips. Newer designs are supported through in-kernel brcmfmac and brcmsmac drivers which are well supported and actively maintained.
Poor WiFI performance on RPi3B (and every other RPi board that I used) is a radio signal issue, not a chip or chip-choice issue. An external antenna connector would solve the issue, but I guess when you're intentionally cost-engineering boards for short-range hobbyist use there are design compromises to make, and perfomance comes second to cost.
It's a simple question with a non-simple answer. If you are playing H264 media the latest version works best. If you are playing HEVC media you will find the lack of hardware decode for HEVC on the RPi3 boards to be a challenge and shouldn't expect 1080p media to play well. Older LE 9.2.6 contains optimisations that (combined with some overclocking) allow most 1080p software decoded HEVC media to play, but those optimisations are not technically possible to include in the current releases and 9.2.6 is ageing so you may find issues with TLS certificates and older/unmaintained add-ons and online media sources may have challenges.
It was either Realtek RTL8189ES or RTL8189FS .. I forget which.
The wl driver has been unmaintained for years so hearing it panics doesn't surprise me. Share the report and a dmesg log in a separate thread.
The H4 should support EFI boot, which opens the door to using efibootmgr which can be installed from one of the tools add-ons in the LE repo (system-tools?). See https://linux.die.net/man/8/efibootmgr or https://wiki.gentoo.org/wiki/Efibootmgr. You would be able to combine efibootmgr with some custom buttons on a remote that configure the EFI boot entry to reboot to.
To confirm: You are saying that PCSX games work fine under Lakka on the same RPi4 hardware, but not under LE?
