Posts by chewitt

  • Matricom G-BOX Q1

    dtech maintains an LE 9.2.8 image for Meson-8 hardware but he's announced support will come to an end with the release of LE13; not sure if the current state will help with issues with scrapers or not (but you have nothing to lose). There is nothing newer from LE as the mainline kernel for Meson-8 is still in a too-basic state for images and progress is glacial.

  • [RPi4] USB DAC disconnects

    It's not really possible to corrupt the core OS as LE packages kernel and userspace into two squashfs files that are expanded on boot into a virtual read-only filesystem. If you corrupt either file on the SD card they fail to decompress and the OS fails to boot. Once the OS has booted; 99% of important things are read-only. For kicks please experiment with the latest LE13 nightly on a spare SD card; it has newer kernel/drivers than LE12.2.

  • [RPi4] USB DAC disconnects

    As the DAC uses generic usb-audio drivers used by tens of millions of devices, it's probably NOT a driver problem.

    Two suggestions (test them separately):

    a) If the device is connected to a USB 3.0 port, move it to a USB 2.0 port (some CMedia devices prefer 2.0)

    b) See if adding usbcore.autosuspend=-1 to kernel params in cmdline.txt changes the behaviour

  • [RPi] WiFi Issues -> Try disabling 802.11ax mode on router

    The Broadcom chips used in RPi4/RPi5 support WiFi 5 (802.11ac) but not WiFi-6 (802.11ax) so in theory disabling that feature in the router should not impact them as you're disabling something they cannot use. That said, this is radio where everything interferes with everything else so perhaps disabling 'ax' results in better 'ac' or 'n' or whatever standard the cards are connecting at.

    NB: LE13 nightlies have improvements that result in nobody reporting 'invalid-key' there for some time.

  • Subtitle Synchronization

    Quote from dmht13

    I [snip] add subtitles to recordings that come from DVB-T/S and subtitles come from opensubtitles.com

    The better approach would be to record the original subs broadcast with the media you are recording. Then things are in-sync from the start. The subs on opensubtitles are aligned to the media rips they were sourced from, and beyond your recordings having the same movie/show name as those rips there's nothing in-common; hence the previous comment about needing to resync the subs to the (different) media you have. The other approach if things are only a little out, is to map the subtitle +/- delay controls in Kodi to some spare buttons on a remote so you can adjust things on-the-fly without having to navigate into menus all the time.

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