Posts by chewitt

Connect the installer USB to something that can edit the syslinux.cfg file in the boot partition; locate the run entry and append textmode to kernel boot params there. Boot from the USB and when prompted type run and it will boot to a text console instead of attempting to run Kodi. Connect a USB keyboard and you can check the internal storage of the board is mounted under /var/media and find the boot partition where its copy of syslinux.cfg exists; edit the file to disable the rogue display connector that Kodi is trying to use (same issue and fix as Wayland). Reboot with the installer USB installer removed and Kodi should come up. Add ssh to boot params too so that you can access the board over the network in the event there's still more digging around to be done.

I have a hunch the random problem is related to bandwidth on the HDMI connection. HD audio formats require more than non-HD media and can cause problems. This can be a problem with cables (not using HDMI certified cables). It can also be a problem with the Intel GPU drivers prioritising video bit-depth (they don't account for audio needs). It can also be an issue with firmware if the system outputs HDMI through an LSPCON chip and some users end up using an external DP-to-HDMI dongle (which also has firmware, but different to the onboard one) to mitigate issues. It can also be a combination of "all of the above" resulting in no clear obvious solution.

The main suggestion and starting point would be to bump to a current LE13 nightly so that newer drivers and a patch that clamps video bit-depth to 10-bit output (the max used with modern media) are used.

The OS should be running in the background but for some reason (usually an issue with display/GPU drivers) Kodi does not start or outputs to the wrong screen so you are left looking at the bootsplash not the home screen. If you add "ssh" to kernel boot params the daemon is forced to start on boot allowing you to connect Ethernet and SSH in to share the system log via pastekodi (share the URL generated here) so we can hopefully see what's happening. NB: Please use a current LE13 nightly image for testing.

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.

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.

Most odd. Does the device show up again when reconnected to the USB 3.0 port (with autosuspend=-1 set)?

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

I don't see any submitted patches to address this topic: https://patchwork.kernel.org/project/connman/list/ so I would assume it has not been reported. So you need to report findings to ConnMan developers via their mailing list: [email protected]

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.

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.

Please share a Kodi debug log that demonstrates the behaviour.

I'll flag the problem internally but I won't guarantee quick resolution. FWIW, that mirror isn't reachable from the UAE either so it's not an IL specific issue.

It's worthwhile powering everything down, disconnecting cables, leaving everything for 20 mins (have a cup of tea/coffee) and then reconnect and power things on again. As dumb as that might sound, it frequently seems to work for CEC problems.

There is nothing obvious in the logs. Hence I've asked you to follow basic common sense troubleshooting 101 basics using a spare SD card. I'm not going to request it a second time. Your call on the next move.

Quote from atirage21

I waited better support from this forum.

Family and work has a higher priority than your harmless cosmetic CPU temp non-bug. Feel free to ask for a refund.

For kicks I would take a spare SD card and the latest LE13 nightly and see if the problem is repeatable with default Estuary skin and stock configuration and without the unmaintained VPN addon that fills your logs with junk.

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' ^

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 ^

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.

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?

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.

Quote from Mayoru

How is that possible?

Old laptops are typically larger, consume more power, generate more fan noise when used in a confined space, and either offer less or not-much-more capability. Yes the CPU is likely faster and GPU more capable, but RPi4/5 boards are a well optimised package for LE use and a good compromise of features/capabilities/stability. There's no right/wrong answer tho.