Display MoreHey Libreelec Masters
Kan someone explain what it means for nvidia users
2025-11-15 (c4b4dea): #10669 mesa: update to 25.3.0
what i can understand vaapi takes over and does hw acceleration as be fore but its nvidia capable now
Can i use my rtx5070 now? i hope heheh
Regards
Nvidia is still only included in Generic-legacy (X11)
INTEL/9462.NGWG.NV is a 2230 M.2.
Though based on dmesg iwlwifi is identified, but not coming up either.
lspci/lshw should show it.
But the USB device looks like some kind of wireless.
you may be able to figure out more using a ub7ntu live cd, or given it is a pc primarily made for windows, boot into windows and find out what these devices actually are, and the drivers I use.
we can see
Port 8: 0000.0101 power connect
We can see that there is likely a composite device plugged in to this bus. I’m guessing it is a USB device internal on you pc, that requires a driver. But can’t identify what this device is.
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/8p, 480M
|__ Port 008: Dev 002, If 0, Class=[unknown], Driver=[none], 12M
|__ Port 008: Dev 002, If 1, Class=Wireless, Driver=[none], 12M
Yes. We don’t have build capacity to run 2 full (13/12.2) and addons daily.
When there is change then the schedule kicks off, but when only addon changes are done, then addons need to be built … Also jobs are only run for 24 hours …
So the real answer is - the needed jobs are prioritised over “building for the sake of building” - of which le12.2 image would be.
Hope that give the insight into the schedule.
Now a lsusb -v please
Sorry. But I can’t follow what has been shared.
Just juggling builds.
Can you please share the boot dmesg and lsusb -t without any usbs plugged in?
Is there any error?
Then plug in the USB devices one at a time to identify which one is causing the error.
Once we identify the faulty device then we can look in to the lsusb -v data
So looking at this - please run -
lsusb -t
It looks like the composite device has come online, where it did not during the boot process.
So when testing tomorrow. Try with no USB connected, that should isolate the error down.
I don’t think the “device connected” is coming online.
If Disconnecting all USB, does the error occur?
When connecting the haobo you get the 1-7 and 1-8 messages?
The device descriptor read/64, error -110 means a conn3ction establishment error, sometimes that a that USB port power supply was exceeded. Can you please disconnect all USB devices and reboot, and then add them back one by one to identify the failing device.
I can see the keyboard as 1-7.
Also please share the lsusb from the system.
2C:CF:67:2C:88:8D is the onboard (wlan0)
70:15:FB:10:B1:1B is the intel (wlan1)
Service.nextpvr installs ffmpeg-tools and I tried to find ffmpegx and couldn't. I installed TVH too but couldn't find it in .Kodi. How do I find it?
I did try to use -f v4l and thought it was my lack of understanding causing the missing ioctl messages.
The ffmpegx built binary is .kodi/addons/tools.ffmpeg-tools/bin/ffmpeg
Guessing the kernel update. - 6.15.6 to 6.16
Is ssh / samba working? Just the display (or all)
lutz108 both LE12.2 and LE13 have librespot 0.7.1 which incorporates the fixes you have referenced.
Moving all the reports from GitHub to here.
- https://github.com/LibreELEC/LibreELEC.tv/issues/7166
- https://github.com/LibreELEC/LibreELEC.tv/issues/8731
- https://github.com/LibreELEC/LibreELEC.tv/issues/7353
- https://github.com/LibreELEC/LibreELEC.tv/issues/10573
- https://github.com/LibreELEC/LibreELEC.tv/issues/8762
- https://github.com/LibreELEC/LibreELEC.tv/issues/8760
Some of the feedback / known issue / suggestions on the issues - please try these first.
**not recommended** - but has helped some.
/etc/modprobe.d/iwlwifi-opt.conf
Add the line "options iwlwifi 11n_disable=1" (without the quotes)
There is a report that on “unclean restart” connman always returns “invalid”
LE12.2 (nightly) and LE13 (nightly) both have the most recent iwd and connman. So any testing should be done against these releases. The kernel on 12.2 (nightly (6.16.12)) has diverged from LE13 - which is now 6.17.x on all except RPi, so testing should be performed on LE13 if not RPi.
As in the issue logs a number of detailed scenarios have been run though, with some success. There seems to be a number of corner cases that cause the issue (including the known ones above) - the interesting observation on https://github.com/LibreELEC/Libr…ment-3395445892 is the DFS and 80. E.g. Does this occur on a simple 20 channel…
Note - I test using a C9130AXI-Z 802.11ax 2.4 GHz/5 GHz access point at 20 MHz, no FT, no WPA3. Also test against Unifi AC Mesh.
iwd and connman are synced up to that of LE13.
Correct there is no b43 in LE12/13. I don’t see the wl driver returning in LE with “patches”, the decision to drop it was only made after the inability to obtain working patches across multiple kernel releases, and lack of support (community) - lots of reading and research done in the PR and issue, with references to the issue.
The wireless positive with LE12.2/13 is the now available upstreamed rtw88 wireless.
