Posts by chewitt

  • [RPi4] Weird delay on first play after start

    Code
    2026-07-09 20:31:46.691 T:1228    debug <general>: OnPlayBackStarted: CApplication::OnPlayBackStarted

    In the log this is the first invocation of a 'play' ^

    Code
    2026-07-09 20:31:48.494 T:1455    debug <general>: Open - av_find_stream_info finished

    Stream info search has completed within 2 secs ^

    Code
    2026-07-09 20:31:48.969 T:1455    debug <general>: CVideoPlayer::HandleMessages - player started 2

    And by this point audio has synced and playback is started ^

    So i'm not seeing a two minute delay from the invocation of playback to playback starting.

    Code
    2026-07-09 20:30:35.747 T:1279     info <general>: VideoInfoScanner: Starting scan ..
...
2026-07-09 20:31:46.691 T:1228    debug <general>: OnPlayBackStarted: CApplication::OnPlayBackStarted

    However there's a 75 second gap between an update scrape/scan of the USB drive and the playback event starting. Do you have Kodi configure to update the library on start? .. perhaps this is the delay you are seeing?

    Code
    Jul 09 20:31:28.529486 Raspberry sh[1197]: SG_IO: bad/missing sense data, sb[]:  f0 00 01 00 50 00 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 09 20:31:28.530216 Raspberry sh[1197]: /dev/sda1:
Jul 09 20:31:28.530216 Raspberry sh[1197]:  setting standby to 12 (1 minute)

    NB: This ^ is also logged in the journal, but this is harmless. It's the result of hdparm configuring standby on the drive and the USB/SATA adapter not implemented all of the SCSI command set (common on cheap SATA bridges) so the kernel doesn't see responses to everything it gave instructions on and it logs this.

  • [S912-H] Trying to install the latest stable LibreELEC 12.2 (2025.11) on the Minix Neo U9-H

    You can add ssh and video=HDMI-A-1:1920x1080M@60D to boot params in uEnv.ini and see if that helps? - The first forces the SSH daemon to start on boot so you can find the IP from another device and log in. The second forces the initial DRM state to 1080@60 output; sometimes it will run at 4K and TV's don't always agree with that. The display.service failure is harmless; this is from the VFD driver service (it fails as the U9-H has no VFD display IIRC). It has absolutely nothing to do with HDMI output.

    The LE13 images here: https://chewitt.libreelec.tv/testing/ run a newer kernel with some changes to HDMI/DRM things. You'll also find a U9-H image there (for eMMC install) but mainline u-boot support is still in a rather experimental state and when you hit issues with that image I have no time or interest for bug-hunting right now, so I would suggest sticking with the box image on SD card so that vendor u-boot is used. As much as I loathe vendor boot code it's probably doing a better job with that hardware.

  • Call to Action for Tvheadend users!

    emveepee We could create a standalone scan-tables add-on for users to install (is that what you were thinking?) but I'm not sure the extra complication of that is justified. The scan tables are updated infrequently (both upstream LinuxTV and the Tvheadend fork) while the DVB server apps are updated relatively frequently; so if you just bundle the tables into the NextPVR add-on the latest table updates will be distributed to users without much delay. IMHO content quality in the tables is a much more pressing issue.

  • [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.