Posts by chewitt

  • LE11/12: CIR Stops Working after Upgrade

    From the problem description it's sounds like a kernel issue, so triage needs to involve building custom LE images with kernel changes that attempt to pinpoint changes to the nuvoton driver. The normal git bisect workflow (on the whole kernel) will be challenging to do as rolling back to a much earlier kernel requires more than just the kernel githash to be changed in the LE buildsystem, and you'll end up going down a rabbit hole of changes. I would instead see if there are interesting looking changes that can simply be reverted to see if anything has a positive impact.

    This is the history of the driver: https://github.com/torvalds/linux…c/nuvoton-cir.c

    If you are sure that problems start around the 5.x to 6.x transition we have to look back some way. Most of the changes look not related and harmless. The first one that sounds a little interesting to me is https://github.com/torvalds/linux…e6233beadc650c4 but to set expectations, I'm not a code guru.

    However, to illustrate the process and test the theory I would git clone kernel sources and then revert that specific change with "git revert 4345e2e5c75895232a17e6783e6233beadc650c4" .. and if we are lucky this will revert cleanly. If it does, you can then do "git format-patch HEAD~1" to create a diff patch of the revert commit and copy the patch file to packages/linux/patches/ in the LE buildsystem. If you now respin the image, the buildsystem will detect the patch and only rebuild the kernel package with the patch applied, and then you can test the image. If the git revert fails, it's because there are other changes to the same code area since that commit, then and you need to revert the commits that touch the code in reverse sequence, and that will either be a relatively simple task with a couple more steps (and generating a few more patches to copy/respin/test) or it'll be a huge challenge. The nuvoton driver doesn't look like it had that much real-world change in recent years though, so I have a hunch specific commits will be okay to revert and test. No promises though.

    The problem description shows you have a moderate level of Linux skills (enough to compile images at least) so hopefully you might have half a clue on what I'm rambling on about :)

  • [RPi4] Out of Memory Error

    I doubt it's a memory leak, but without understanding the configuration of the device in more detail it's hard to comment. NB: If the problem is a leak then a 2GB or 4GB device will not fix the problem, only delay the failure.

    Run "pastekodi" and "pastecrash" and share the URL's generated.

  • [RPi5] Trying to get bluetooth remote "OK" button to send an "ENTER" code?

    Code
    echo "evdev:input:b0005v0508p1980*" > /storage/.config/hwdb.d/99-UR02.hwdb
echo " KEYBOARD_KEY_c0028=enter" >> /storage/.config/hwdb.d/99-UR02.hwdb
reboot

    ^ That would be the correct format for a hwdb entry based on the info shared, but if the OK key is listed in evtest and can wake the RPi from screensaver I don't think that's the problem. One of the BT remotes I have needs a hwdb file creating to make the enter button work, and without the file is does absolutely nothing. No harm in experimenting tho. Worst case it does nothing and you can delete the file again afterwards.

  • [RPi5] Trying to get bluetooth remote "OK" button to send an "ENTER" code?

    Reboot. Once the home screen shows, SSH in and run"journalctf -f", then fiddle with buttons on the remote so it reconnects; which should be visible and obvious in the journal. Once the remote is connected, run "cat /proc/bus/input/devices" and you should now see the input devices registered by the remote. I think the current issue is simply that when the RPi5 is booted the BT remote is not automatically reconnected (until you press buttons) so there is correctly no input device listed.

    True ??

  • RPi4 LE12 connects via WIFI and LAN but only via LAN it connects to shares

    I think you need to increase the "wait for network" timeout value in the LE settings add-on from the default 10s? to something like 30s. If the device is LAN connected this has no impact on startup time as the network is up before Kodi starts. If the device is WiFi connected then the kernel drivers load fairly quickly but some access points (routers) take longer to associate to, so Kodi needs to intentionally wait (longer) for the network to come up before trying to connect to MariaDB/shares. Kodi only tries to connect once at startup and if the network is not up the connect fails and Kodi defaults to local sqlite DB files (which are empty).

  • Bluetoothctl Seg Fault

    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. /shrug

  • Bluetoothctl Seg Fault

    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.

  • NO_CERTIFICATE_OR_CRL_FOUND errors preventing any https connection (from addons at least)

    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.

  • NO_CERTIFICATE_OR_CRL_FOUND errors preventing any https connection (from addons at least)

    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?