Posts by chewitt

  • LibreELEC Add-on: Add Screen configuration setup

    LE has no plans to implement this because manual monitor selection from within the Kodi GUI is a Kodi (not LE) feature. Based on recent discussions it's something that Kodi might finally implement for Kodi v23 (Q*) .. but no guarantee.

    Until then you can enable SSH to access the OS, then mount the boot partition and edit kernel boot params to disable the internal (normally LVDS) connector so that output defaults to HDMI instead of the internal screen.

    See https://wiki.libreelec.tv/hardware/intel…generic/laptops

    NB: Kodi does not support pre-execution configuration of the output device, which is what would be needed to configure anything from the LE settings add-on. Someone proposed it, but a) not quite the right way, b) the contributor didn't persist to see changes through so the PR was closed: https://github.com/xbmc/xbmc/pull/27412

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