Posts by chewitt

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

  • [x86-64] Black screen after bootsplash

    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.

  • Multi channel PCM issues

    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.