Posts by chewitt

  • [x86-64] CEC Mapping by libCEC

    This image https://chewitt.libreelec.tv/testing/LibreE…-12.95.1.img.gz has the following patch applied:

    See if that works? - Note that DP/USB-C adapters need to be an 'active' type that supports CEC tunnelling; and even then there's no guarantee that the CEC pin has been physically wired up.

  • Call to Action for Tvheadend users!

    The overall set of scan tables that LE bundles (upstream LinuxTV repo) aren't the same that Tvheadend bundles (own repo with extra commits) but the DVB-S tables for Astra-1{M|N|P}-19.2E appear to be the same in both locations and were updated in the LinuxTV repo from Lyngsat/KingOfSat three months ago.

    Perhaps a blind scan with wscan2 needed? .. but I'll let others comment on troubleshooting suggestions as I'm not an experienced Tvheadend user.

  • [RPi4] Timeout and digest mismatch when accessing official add-on repository

    The government "Sovereign Internet" project mandates all service providers to have such capabilities and the communications regulator provides a frequently updated monitoring (block) list that must be implemented. It's unlikely that our infrastructure is deliberately targetted. More likely something objectionable is or has been hosted with DigitalOcean and Hetzner (where we host things) and their ASN ranges are configured instead of specific sites or IP's and we're just collateral damage.

  • [RPi4] Timeout and digest mismatch when accessing official add-on repository

    The "index has wrong digest" logged error is probably the result of the download failing so you end up with a truncated .xml.gz file that doesn't match the published sha256 checksum. Add-ons are hosted directly (not mirrored like release images) but the addon server infrastructure is not overloaded and there is no active traffic management (bandwidth throttling) on our side. If there was a global problem with our infrastructure we'd see a ton of user reports, and we're not, which suggests a localised issue; something about your network or the connection between you and our infrastructure.

    For kicks you can experiment with a current nightly on a spare SD card, but you should see the same problem since your requests are hitting the same server/infrastructure on our side.

  • Official LE13 Test Images for Amlogic (Kodi-22)

    The images in my share now synthesise a MAC address for the BT interface from the CPU serial and set this on boot to workaround issues where the (Broadcom) chipset ends up with a factory-default address which BlueZ ignores; resulting in BT not working. This is the correct resolution for the lack of working BT on WeTek Play2 boxes, which has been reported a few times, and likely impacts a few other devices too. The appearance of a BT 'regression' in LE 12.0 is the result of Linux 6.5.y kernel changes (LE 12.0 shipped with Linux 6.6.y) where the btbcm driver reverted to an earlier (stricter) handling of factory-default addresses. I was never able to track the cause down when previously looking; but now with help from Claude the dots were finally connected.

    At the moment the MAC setting is done in the btmactool buildsystem package but I will probably rework this and ethmac tool into a common package before it gets upstreamed to main repo.

  • SAMBA password authentication

    In modern Windows OS the SMB client MUST use authentication. So you need to set a user and password and enable auth on the Samba server. I forget whether it's required but since it's quick; reboot after changing/resetting the config. Also ensure the Samba server min/max version settings are correct, e.g. min SMBv2 and max SMBv3 and not min/max forced to SMBv1 as modern clients no longer speak the SMBv1 dialect.

  • Can I add WiFi config to SD card pre-install? (headless setup)

    Quote from Paul Webster

    I know that this thread is ancient ... but ... is there still a way to preconfigure WiFi?

    There never has been a way to preconfigure it (LE has never packaged os_config.json). I'd suggest you force the SSH daemon to start by adding "ssh" to boot params in cmdline.txt and then connecting an Ethernet cable. As you have not configured an IP on the RPi it will auto-configure itself with a 169.254.x.x/16 address. In the absence of DHCP the device you need to connect from should also self-configure itself in the same range (which is a large range) and you can run arp -a or perhaps ping the broadcast address (the .255 address of the local subnet) to discover the other device's IP address; and then connect over SSH. Once connected over SSH you can run connmanctl > agent on > scan wifi > connect <name-of-service> to configure the network connection, and use kodi-remote to navigate around the screen. If you struggle with the remote IP discovery another approach is to have your computer connect to WiFi and then share its connection via Ethernet to the RPi, which results in the RPi using a known IP subnet that requires less guesswork.