Posts by chewitt

Quote from Da Flex

Jul 12 17:54:41.968605 HTPC (uetoothd)[932]: bluetooth.service: Referenced but unset environment variable evaluates to an empty string: BLUEZ_ARGS, BLUEZ_DEBUG

^ This just means bluetooth.service https://github.com/LibreELEC/Libr…service#L10-L12 did not find either variable defined in the respective .conf files. It is harmless and if you check your own devices you will see the same boot time message.

If possible please test with another distro that uses a recent BlueZ version, and with a different BT dongle device.

If the issue occurs on another distro it's nothing specific to how LE has compiled BlueZ or a problem interaction between BlueZ and core OS functions in libc. If the issue remains with another BT device on LE it's either compile or something in the comms between the Soundbar and BlueZ. If the issue doesn't occur on other BT hardware, it suggests kernel driver or firmware.

Also possibly related https://github.com/xbmc/xbmc/issues/23785

Seems to be something in Kodi as the same is reported on Android https://github.com/xbmc/xbmc/issues/25118

Please run "dmesg | paste" and "lscpi -nv | paste" and share the URLs so we can see if anything is in the boot log (missing firwmare or such) and what the card IDs are. It should be supported in Linux 6.9.y https://github.com/torvalds/linux…44c4b9203f3ec9a unless it's not the same card variant or has different PCI device IDs.

NUC5 should have enough CPU grunt to software decode HEVC and other codecs up to 1080p resolution. I doubt it will handle 4K media though. There's no harm in setting it up and seeing if it meets your needs.

The segafult is in bluetoothctl which comes from the BlueZ package, so perhaps update to an LE13 nightly. At the moment these are still using the same kernel as LE12 (we will bump to Linux 6.10 in a week or so when it releases) and same Kodi version as LE12 (the bump to Kodi Piers will also happen soon) but the BlueZ version and some background compiler dependencies are already newer.

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.

ping garbear= ^

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.