Posts by chewitt

  • [x86-64] Boot-up and install weirdness - no GUI

    Install a current LE13 nightly to the Dell box. Assuming that doesn't magically fix things, next boot the Linux Mint install in 'Live' mode so you can mount the boot partition of the internal drive and edit syslinux.cfg to append ssh to kernel boot params. Now when you boot the problem LE install again the SSH daemon is forced to start on boot so you can SSH into the box to run pastekodi and share the log URL that's generated; which hopefully shines a light on what the underlying problem is. In the absence of some logs/info we are blind to what the issue might be.

  • [RPi5] LE13 - DRM Prime hardware decoding and D2P makes PVR fail

    I'm aware of those PR's/changes and I've understood them to resolve past issues with content appearing in the top-left corner of the screen; hence asking you to run a current LE13 nightly. That said, the general design/test assumption is that users run the desktop at 1080p to give a better navigation experience and switch to 4K only when needed. You've confirmed that works, but i'd guess some of the logic or code-maths is still broken for the less common 4K switching to 1080p when needed case. I'll flag it to the dev who's looked at those cases.

  • [Odroid-C2] No Video To HDMI If Projector Is Booted After Odroid

    Power up the projector. Power up the C2. As long as the screen is showing SSH in and run getedid create then power the projector off, reboot the C2, wait a minute, then power on the projector and you should see Kodi? (and this should be persistent). In short, this captures the EDID data from the active HDMI connection and hard-codes the kernel (and thus Kodi) to always see the HDMI device (the projector) as connected.

  • Waipu TV ?

    B2 (imminent) > RC1 (soon) > maybe RC2 > release. I'd expect release in Autumn. There's a strong desire to get something shipped sooner than later else we'll keep queuing changes and go nowhere.

  • Multi channel PCM issues

    Quote from duffbeer

    Never done this before so please bare with me if I make a mistake.

    Enable 'debug logging' at Settings → System → Logging. Neither of the logs are Kodi debug logs, so lots of info missing.

    Also leave media to play for a full minute before running the command so the playing configuration has settled.

  • Multi channel PCM issues

    Please share a couple of debug logs using the LE13 image and the pastekodi command so we see kernel and other infos alongside the Kodi log; one with successful playback as desired, the other where things are not working. Share the URLs generated.

  • [RPi4] USB DAC disconnects

    The only unusual thing that I see in the log is related to time/timing:

    As RPi4 lacks an RTC time starts at the libc release date and then after the network is up NTP syncs the clock, so there's an initial large time jump forwards:

    Then the next item is an SSH login:

    Code
    Jul 26 17:30:01.911967 Bedroom4 sshd-session[1067]: Accepted password for root from 192.168.86.236 port 53399 ssh2

    Then 3.5 mins later there's a USB device connected:

    Code
    Jul 26 17:33:27.301690 Bedroom4 kernel: usb 1-1.1: new full-speed USB device number 3 using xhci_hcd
Jul 26 17:33:27.395029 Bedroom4 kernel: usb 1-1.1: New USB device found, idVendor=0d8c, idProduct=0012, bcdDevice= 1.00
Jul 26 17:33:27.395906 Bedroom4 kernel: usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 26 17:33:27.396525 Bedroom4 kernel: usb 1-1.1: Product: USB Audio Device
Jul 26 17:33:27.397049 Bedroom4 kernel: usb 1-1.1: Manufacturer: C-Media Electronics Inc.
Jul 26 17:33:27.405023 Bedroom4 kernel: input: C-Media Electronics Inc. USB Audio Device as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.1/1-1.1:1.3/0003:0D8C:0012.0001/input/input2
Jul 26 17:33:27.461692 Bedroom4 kernel: hid-generic 0003:0D8C:0012.0001: input,hidraw0: USB HID v1.00 Device [C-Media Electronics Inc. USB Audio Device] on usb-0000:01:00.0-1.1/input3
Jul 26 17:33:27.585045 Bedroom4 kernel: usbcore: registered new interface driver snd-usb-audio
Jul 26 17:33:27.641991 Bedroom4 (udev-worker)[1142]: event2: Process '/usr/bin/evrepeat -d 500 /dev/input/event2' failed with exit code 1.
Jul 26 17:33:27.796375 Bedroom4 Boot[1207]: ### Setting up sound card ###

    RPi4 has 2x USB 2.0 ports (furthest away from Ethernet) and 2x USB 3.0 ports (next to Ethernet). The lsusb log clearly shows the DAC on Bus 001 which is the USB 2.0 bus (note the root hub type):

    Code
    Bedroom4:~ # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 003: ID 0d8c:0012 C-Media Electronics, Inc. USB Audio Device

    This behaviour correlates with numerous online reports of CMedia audio devices not liking USB 3.0 ports, but in the lsusb log the device doesn't show up until the fourth connection attempt. As there are only 4x USB ports (and assuming no user error) this would imply one of the previous three attempts was also to the other USB 2.0 port and the device didn't show up. Other than user error I'd have no explanation for that.

    The kodi log shows the same timezone jump; marked by a failure to find releases.json as the TLS certs are probably invalid due to the wrong host datetime, which is all normal:

    Code
    2025-06-26 04:44:46.754 T:960     error <general>: SETTINGS: load_url # Error loading url: http://releases.libreelec.tv/releases.json
                                                   Reason: [Errno -3] Temporary failure in name resolution
2026-07-26 17:28:23.975 T:960      info <general>: SETTINGS: __init__ # updateThread Started
2026-07-26 17:28:23.977 T:960      info <general>: SETTINGS: set_auto_update # auto
2026-07-26 17:28:24.161 T:1039     info <general>: SETTINGS: run # Waiting

    but then Kodi appears to be in a waiting state trying to find the 192.168.86.216 device:

    Then finally some 1.5 mins later (3.5 mins after the initial timezone jump):

    The reason timing stood out to me is that Kodi only evaluates its audio devices at startup (there is no hotplug support) and the logs show the DAC device, despite the long 3.5 mins stall period between timezone jump (network up, which Kodi waits for) and the DAC being connected. It's like Kodi is waiting for the DAC ??

    Regardless, none of that would explain the original issue report of DAC disconnects though. The normal reasons for that would be power draw on the USB bus, or perhaps bad USB cables or issues with physical USB connectors.

    So back to basics. Please go try a current LE13 nightly on a spare SD card with clean Kodi config and the DAC connected to working USB ports (which are 2.0 not 3.0) and a different USB cable. Use usbcore.autosuspend=-1 in kernel boot params in cmdline.txt again if no difference.

    Pinging popcornmix to see if he has any ideas too.

  • Multi channel PCM issues

    I've been running LE13 nightlies on an assortment of hardware for the last ~2 years and aside from self-inflicted issues, there have been few to none, so go experiment as it might resolve the issue and avoid the need for new hardware. I've no specific knowledge on NUC14 support but LE13 is on Linux 7.1 so it probably just works. The N150 box I have here for tests works without problems.

  • LE13 on Radxa ROCK 5B+

    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?

  • LibreELEC NTFS support through a desktop computer

    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.

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    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.