Posts by klh939

After much research I got nowhere. Compelling evidence suggested the problem lay in the BIOS setting but as this is a Lenovo laptop there are no "advance" settings to mess with. However I spotted a BIOS setting for the xHCI USB - disabled, enabled, auto or SmartAuto. I set it to disabled and BINGO the DAC was seen from boot. Unfortunately that completely messed up suspend/resume so although I can now see the DAC from boot the system is less usable.

So, I am giving up trying to use the DAC. LibreElec on the PC is working perfectly well and the audio over HDMI to the receiver is good enough.

thanks for all the help

Thank you......It still confuses me that the DAC works if I hotplug it but doesn't from boot. I guess one of the quirks may be associated with boot

I have been looking again at "simulating" a hotplug. I would have thought some form of reset would trigger LibreElec finding the DAC. I tried unbind/bind of the PCI connected USB controller. the unbind works and the USB devices dropped off - no longer reported by lsusb. However the bind only put back the devices that were there before. So the PCI controller is not getting reset. More digging required.

Hi Mglae, not sure what to do as a result of your post.

Is it possible to change the quirks being selected without rebuilding LibreElec?

Of the two laptops which exhibit the problem I have fixed one (HP) by changing a bios setting. There was a system configuration setting "USB3.0 Configuration for Pre-OS" that was set to "enabled" which configured the USB port s to USB 3.0 controller. Changing this to "auto" means the USB ports are set to USB 2.0 in pre-boot and switched to 3.0 after boot. So auto fixed this laptop

No such setting on my target laptop (Lenovo) and so other settings for the USB port configuration.

So still stuck

Thank you for the suggestion

I used a USB stick with what is essentially the same LibreELEC installation and it works perfectly....wel the DAC hotplugs and is detected at boot.

lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0c45:671e Microdia Integrated_Webcam_HD
Bus 001 Device 005: ID 20b1:0002 XMOS Ltd XMOS USB Audio 2.0
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 05e3:0764 Genesys Logic, Inc. USB Storage
Bus 003 Device 003: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 003 Device 004: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 003 Device 005: ID 27c6:5301 Shenzhen Goodix Technology Co.,Ltd. Fingerprint Reader
Bus 003 Device 006: ID 0bda:b00b Realtek Semiconductor Corp. Realtek Bluetooth 4.2 Adapter
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

ls /dev/snd/by-path/
pci-0000:04:00.1                pci-0000:04:00.3-usbv2-0:2:1.0
pci-0000:04:00.3-usb-0:2:1.0    pci-0000:04:00.6

That would suggest the DAC is good but my target laptop/LibreELEC installation has an issue.

I decided to get out all my old laptops, yes I am a sad persons that keeps those old devices.

I have 3 old laptops in addition to the one I want to use for LibreELEC. I tested each, two work perfectly in that the DAC was detected during boot, the other failed in the same way as the laptop I am targeting for LibreELEC.

[the reason I want to use the specific laptop for LibreELEC is because the screen "fell off" which doesn't matter as I will only ever connect it to a TV so it would be perfect for a media centre]

I dug out a Linux Mint installation on a USB stick and booted that on the failing laptops. After hotplugging the DAC I used hwinfo to locate what devices are involved

USB:XMOS device is attached to a USB hub which in turn is attached to a PCI hub controller. For both failing laptops the PCI connected USB Controller is an Intel Wildcat Point-LP USB XHCI controller, revision 0x03.

Doing the same investigation on the laptops that worked showed that the PCI connected Controllers were AMD devices (different ones)

I noticed that the report for the PCI connected controller reported that the activation command was "modprobe xhci-pci" but as thats a builtin I cannot remove/restart it

so, not quite a dead end but no success either

Thank you for the pointer....

I did some exploring of /dev

there are three ports on the laptop so

ls /dev/bus/usb
001  002  003

makes sense

looking at each port

BEFORE:

ls /dev/bus/usb/001
001  002
ls /dev/bus/usb/002
001  002  003  004
ls /dev/bus/usb/003
001

AFTER:
ls /dev/bus/usb/001
001  002  003  004  005
ls /dev/bus/usb/002
001  002
ls /dev/bus/usb/003
001

three things added to usb/001, two things removed from usb/003, which I think is odd,

I also looked at /dev/snd

BEFORE:
ls /dev/snd
by-path    controlC1  hwC1D0     pcmC0D7p   pcmC1D0c   timer
controlC0  hwC0D0     pcmC0D3p   pcmC0D8p   pcmC1D0p
ls /dev/snd/by-path
pci-0000:00:03.0  pci-0000:00:1b.0

AFTER:
ls /dev/snd
by-id      controlC0  controlC2  hwC1D0     pcmC0D7p   pcmC1D0c   pcmC2D0p
by-path    controlC1  hwC0D0     pcmC0D3p   pcmC0D8p   pcmC1D0p   timer


ls /dev/snd/by-path


pci-0000:00:03.0                pci-0000:00:14.0-usbv2-0:2:1.0
pci-0000:00:14.0-usb-0:2:1.0    pci-0000:00:1b.0

so there is a major change when I hotplug the DAC with the adding of pci-0000:00:14.0 which must be the DAC, [the DAC is reported by kodi as having two ports, an Analogue and a SPDIF]

I am not sure how to proceed with this investigation

After reading somewhere that udev can make like somethings been hot plugged I experimented with a dedicated rule for my XMOS device putting it in .config/udev.rules.d/ and reloaded. No joy.

Looking in journalctl for udev messages showed nothing about my device OR my new rule. I tried various udevadm incantations to reload rules and trigger events but nothing. So I hot plugged the device and bingo the device appeared in lsusb as expected BUT there were now udev entries in journalclt:

Nov 08 16:56:07 LibreELEC (udev-worker)[2280]: 1-2: Process '/bin/sh -c 'sleep 2; /usr/bin/udevadm trigger --subsystem=usb --attr-match=idVendor=20b1 --attr-match=idProduct=0002'' failed with exit code 1.

Clearly a fault with my rule [--subsystem=usb should be --subsystem-match=usb] BUT these entries don't exist from boot which to me indicates that the device itself isn't being detected at all from boot and hence no udev matching to a rule.

I have tried triggering the reload(?) of the specific device

udevadm trigger --subsystem-match=usb --attr-match=idVendor=20b1 --attr-match=idProduct=0002

and just the USB subsystem

udevadm trigger --subsystem-match=usb

but no joy

I fell for a bad google: "modprobe xx" does not reinstall the xx driver, it just installs the driver and does nothing if the driver is already installed, the driver must be removed first: "modprobe -r xx". So I retried the above but first removing the driver then installing. no joy.

A further experiment with a borrowed USB DAC - a much more power hungry device which still work using USB power. That worked perfectly.....a little odd as it is also an XMOS device

lsusb shows:

Bus 001 Device 003: ID 20b1:3078 XMOS Ltd Ustars Audio

as opposed to

Bus 001 Device 005: ID 20b1:0002 XMOS Ltd XMOS USB Audio 2.0

so still stuck getting my DAC to work

my DAC is USB powered, its low powered so should be no issue. The other DAC I borrowed is a much beefier device and that worked using USB power.

However, desperate times. I have dug out a 5v PSU that connects to the DAC and switched it o external power. Exactly the same problem, the DAC does appear from boot. However I disconnected the PSU and reconnected it and it appears, so it behaves like its been hotplugged.

thank you for the suggestion but I am not exactly sure what you mean by "from autostart" but.....

I looked at dmesg after I hotplugged the DAC:

[  285.191496] usb 1-2: new high-speed USB device number 5 using xhci_hcd
[  285.340212] mc: Linux media interface: v0.10
[  285.811284] usbcore: registered new interface driver snd-usb-audio

I then used modprobe to relaod the drivers (I think):

modprobe xhci-hcd
modprobe usbcore
modprobe snd-usb-audio

no joy

A little more digging.

Although plugging the DAC into another laptop worked as expected with the DAC appearing from boot and after hot plug I decided to check the laptop I am using for Libre ELEC running another Linux.

I used the Mint installation USB and booted to a live Mint and checked with lsusb: the DAC wasn't there. I unplugged the DAC and hot plugged it - the DAC appeared. I also tried a full Mint (22.2)installation, patched upto date and that also failed, so there is a Linux issue with my specific laptop. Very odd

There is no external hub in the way, the DAC is plugged direct into the laptop and the problem is there on all three ports.

If I understand correctly there is an internal hub within the laptop. Is there firmware loaded by LibreELEC for that hub?

[BIOS is the latest from Lenovo]

Thanks for the advice.

Ran pastekodi over ssh and got https://paste.libreelec.tv/musical-koala.log

hope thats what is required

cheers

the DAC doesn't appear in the Kodi setting after boot as the DAC isn't detected by the underlying Linux (lsusb doesn't show it). If i unplug and hotplug the DAC it does appear in lsusb and does appear in Kodi

Having set up LibreELEC I decided to add a USB DAC. Its an USB 2.0 XMOS device and worked nicely on previous systems. I shut down the PC, plugged in the DAC and rebooted but the DAC was not detected (not shown on lsusb). I checked the dmsg but nothing showed up.

I unplugged and replugged and the DAC showed up:

Bus 001 Device 005: ID 20b1:0002 XMOS Ltd XMOS USB Audio 2.0

dmesg showed the following:

Nov 06 19:42:36 LibreELEC kernel: usb 1-1: new high-speed USB device number 5 using xhci_hcd
Nov 06 19:42:37 LibreELEC kernel: mc: Linux media interface: v0.10
Nov 06 19:42:37 LibreELEC kernel: usbcore: registered new interface driver snd-usb-audio
Nov 06 19:42:37 LibreELEC (udev-worker)[1556]: controlC2: /usr/lib/udev/rules.d/90-alsa-restore.rules:5 Only network interfaces can be renamed, ignoring
Nov 06 19:42:37 LibreELEC Boot[1564]: ### Setting up sound card ###

and kodi picked it up perfectly

2025-11-06 19:42:38.199 T:1216     info <general>:     Device 6
2025-11-06 19:42:38.199 T:1216     info <general>:         m_deviceName      : iec958:CARD=X20,DEV=0
2025-11-06 19:42:38.199 T:1216     info <general>:         m_displayName     : XMOS USB Audio 2.0
2025-11-06 19:42:38.199 T:1216     info <general>:         m_displayNameExtra: S/PDIF
2025-11-06 19:42:38.199 T:1216     info <general>:         m_deviceType      : AE_DEVTYPE_IEC958
2025-11-06 19:42:38.199 T:1216     info <general>:         m_channels        : FL, FR
2025-11-06 19:42:38.199 T:1216     info <general>:         m_sampleRates     : 44100,48000,88200,96000,176400,192000,384000
2025-11-06 19:42:38.199 T:1216     info <general>:         m_dataFormats     : AE_FMT_RAW,AE_FMT_S32NE
2025-11-06 19:42:38.199 T:1216     info <general>:         m_streamTypes     : STREAM_TYPE_AC3,STREAM_TYPE_DTSHD_CORE,STREAM_TYPE_DTS_1024,STREAM_TYPE_DTS_2048,STREAM_TYPE_DTS_512

I tried different USB ports but that made no difference. I tried the DAC on another Linux (Mint) system and that picked up the DAC from boot and if hot plugged.

I am not sure how the diagnose this so I would appreciate any help in how to progress this

thank you for any help

I have chased this and now have a solution.

The problem was that when I suspended the system it immediately resumed. Lots og Googling and many a dead end but I discovered that the issue was to do with XHC [I didn't have XHCI]. Looking at /proc/acpi/wakeup I had:

XHC       S3    *enabled   pci:0000:00:14.0

I disabled it:

echo XHC > /proc/acpi/wakeup

This allowed suspend to work BUT the remote & USB keyboard didn't cause a resume and I had to physically press the power button. Both my remote and keyboard are USB connected. A bit more digging and I started to question the setting of EHC1 & EHC2, both were disabled in /proc/acpi/wakeup

EHC1      S3    *disabled  pci:0000:00:1d.0
EHC2      S3    *disabled

I enabled both:

echo EHC1 > /proc/acpi/wakeup
echo EHC2 > /proc/acpi/wakeup

Suspend worked as did resume when pressing a remote control key or USB keyboard key. I refined this to discover that only EHC1 effected my remote & USB keyboard . Of course my changed settings were lost after a reboot.

Time to systemd.

I created a service wakeControl.service in .config/systemd:

[Unit]
Description=wakeControl
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c "echo XHC >> /proc/acpi/wakeup"
ExecStart=/bin/bash -c "echo EHC1 >> /proc/acpi/wakeup"

[Install]
WantedBy=multi-user.target

I enabled this service and started it:

systemctl enable wakeControl.service
systemctl start wakeControl.service

/proc/acpi/wakeup now had this:

EHC1      S3    *enabled   pci:0000:00:1d.0
EHC2      S3    *disabled
XHC       S3    *disabled  pci:0000:00:14.0

Happily this state remained after a reboot.

Hi, looks like I made a newbie mistake with cp, annoying as I am not new to Linux and of course I didn't check.

I now have solved my suspend and resume issue too, which makes the LibreELEC installation better than any other Linux installation I have used [it now works like the Windows one :(]. I will update my other post with the rational and solution

thanks for the response.

I normally backup using disc imaging (windows) or rsync (Linux) and had forgotten about the backup feature in kodi, my error.

Still have no idea why recursively copying the content of the old .kodi directory over the new .kodi directory didn't work but it doesn't matter now, the installation is back with the only issue being suspend/resume.

Thanks again

Hi, this may sound silly but as a newbie to LibreELEC i chose to runs the initial installation from a USB to get a feel for it - choosing "live", then "run" from boot. Thankfully after setting up and testing the system LibreELEC appears to meet my needs so I decided to install it to the PCs SSD.

Having spent quite some time setting up the installation on the USB I wanted to transfer that installation to the hard disc. I initially did this by cloning the USB to the SSD but that still left the installer/live/run question on boot. So I decided to do a proper install and chose "installer", that went well but unsurprisingly created a clean install. No worries, I decided to recursively copy the .kodi directory on my USB to the .kodi directory on the SSD. Unfortunately that didn't work as planned and the new SSD installation remained "virgin". So I had to repeat setting up the system.

Bottom line: all is well but it would be nice to have the option to "clone" an experimental installation to become a permanent one during installation.