Posts by chewitt

Kernel drivers have interdependencies and probe order isn't guaranteed so it's quite normal to see "fail" or "timeout" or "deferred" on first probe until dependencies are resolved and then probe succeeds (often silently or with low noise) later in the sequence. So is there an actual problem?

LE12 uses the 'paragon' authored in-kernel driver which looked good but people started to complain about so there's also an add-on installable option to use the previous NTFS-3G (FUSE) driver which is slower but the same as older LE images and appears to be less problematic. The user experience issue is that NTFS filesystems easily end up in an 'unclean' state and the lack of native fsck tools requires your to reconnect drives to Windows to resolve the drive back into a 'clean' state again.

LE13 nightlies now use the new in-kernel NTFS3 driver (merged in Linux 7.0) which has proper tools support for fsck.ntfs etc. and we haven't seen complaints from people since switching to that.

NB: Using a Linux native filesystem type (EXT4, XFS, etc.) avoids all the NTFS issues in all LE versions.

AV1 is supported upstream on RK3588 but not RK3576; the latter has a different (all new) IP block and nobody wrote drivers yet.

And the train is indeed a little quiet. Curating a working image still requires a large number of patches and as some of the in-flight series have iterated/progressed the number of conflicts between things has gone up, and resolving and figuring out how to solve those problems requires a level of effort that I don't have time and motivation for at the moment. Things are at the stage where the easy option is just leaving things as-is until more of the major bits are merged upstream and the overall patch count reduces to a more manageable level. That probably doesn't play well with the likely timeline for K22/LE13 though. Catch22.

LE runs happily on 2GB boards unless you're planning to run flatpak things or other services in the background. 4GB is fine.

No idea about the issue but the first action to take is (re)testing with a current LE13 nightly. Even if the issue in LE12.2 is identified we have no plans for another release so the fix goes into the newer codebase.

Linux needs to have (Windows) Secure Boot disabled. Everything else is just boot order options or controlling security hardware that's exposed or hidden to the OS, which Linux is lacking drivers for anyway so enabled/disabled is harmless.

I think people imagine a fancy Bluetooth remote must be better; but RF ones are typically the easiest

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.