Having the choice of disabling ASPM or AER I would ever choose ASPM because this is more likely the cause of the error.
I updated to the latest Matt Devo firmware and it turns out I don't need either setting https://paste.libreelec.tv/master-antelope.log
I thought you recommend pci=noaer changed back to pcie_aspm=off
Here is the log with the blacklist removed and toggled wifi on to see it working https://paste.libreelec.tv/driven-polliwog.log
All is good.
Thanks for the info yes it is i915 https://paste.libreelec.tv/noble-bee.log
Here is the log with pci=noaer removed https://paste.libreelec.tv/topical-humpback.log and the error message every 5 seconds so yes I still use it. Is it "required" is hard to define.
Martin
Since alpha2 is close it is time for LE 13 anyway and I did the update to Asus CN60. After a successful migration PVR works for a/v without a hitch https://paste.libreelec.tv/eternal-teal.log so the GPU is supported on legacy but it looks like it is the i965 driver
If disabling ASPM is not working another parameter to try is pci=noaer.
That worked to tame the logs to https://paste.libreelec.tv/tough-mammoth.log
The Kodi GUI won't show until the 'wait for network' timeout is reached and date/time will be wrong as NTP didn't correct it, but Kodi should still run without a network.
The GUI delay issue was the NAS change, but the on screen message was wait for network. I assumed Ethernet was slow but my setting was 10s seconds the delay was 20 seconds after wait for network.
It might be interesting for the OP to try wired networking to see if it network stopping his GUI from starting the service.
`````
I have a CN60 and I checked and it was on 12.02 so I went to the 12.2.0 channel installed it and it is working for me https://paste.libreelec.tv/divine-barnacle.log Of note maybe is ethernet is very slow to start.
I tamed the logs by blacklisting the ath9k and adding the config pcie_aspm=off and fixing an obsolete share and seems to work ok now
I thought it might similar to this issue https://github.com/xbmc/inputstream.ffmpegdirect/pull/320 with confusion between which version of CURL::Encode() and CURL::Decode() are being called.
Martin
I would think it should calls Parse with the constructor and Parse shouldn't even be called ie.
CURL url(m_streamUrl);
Edit: that patch does get pvr.nextpvr's call working.
For pvr.nextpvr on x86_64 here is the crash file https://paste.libreelec.tv/natural-dragon.log I can't tell if it it the Kodi CURL:: Reset() or the one in inputstream.ffmpegdirect()
Martin
As a test I did a test with pvr.nextpvr which has an input stream.ffmpeg option and it fails too at the same point. https://paste.libreelec.tv/heelthy-beetle.log. For the log replace hee with hea apparantely because of of banned forum word
It also crashes on CE nightlies at exactly this same spot.
However it is working in Windows with 22.1.3
2025-10-05 12:54:39.089 T:6361 info <inputstream.ffmpegdirect>: OpenWithFFmpeg - IO handled by FFmpeg's AVFormat
The kernel logs didn't identify that it found anything on this device
Oct 03 19:38:38 LibreELEC kernel: usb 1-2: new high-speed USB device number 2 using xhci_hcdI would expect to see kernel: usb 1-2: New USB device found, idVendor=2013, idProduct=-4062, bcdDevice=##
Do you see anything with find /dev/dvb
If yes the do the journalctl | paste again.
Note the NextPVR server does the /dev/dvb scan on startup and if it is slow to be detected you would need to rescan to find the device. There are also scripts on the NextPVR forum showing how to have the server startup delayed.
Since the device is new to the kernel I don't know how Hauppauge can say LE should have the drivers.
Martin
Do you see the device if you run lsusb
Martin
I think his point might be that the /dev/dvb device isn't being created so the server doesn't recognize it.
Martin
You don't need to install the client pvr.nextpvr on LE if you don't want to. If for example you are using the NextPVR web client to connect to the server you would need to use the LE IP and not the IP of your server or localhost.
This is not an LE issue (or Linux for that matter) so you should post on the NextPVR forum.
You say you have the backend setup so I assume the web setup is finished and configured too. The fact that you are seeing your Windows instance to me means that the problem is that your client pvr.nextpvr settings are set to the IP of the Windows server. Change that in the addon setting. For LE on the same box you can use 127.0.0.1
Note if the client you are using is the Windows client NextPVR.exe it will only connect to the local Windows backend.
Further questions should be on the NextPVR forum.
Any h/w issues would be in the kernel logs. If it is an issue with NextPVR server it would be in the NextPVR server logs.
Also is it all frequencies, just DVB-S frequencies (patch #2) or certain frequencies? It could even be the dtv-scanning-tables.
Martin
Did they tell you if kernel support needed to be added for that firmware? I saw this patch mentioned recently https://github.com/b-rad-NDi/Ubun…ment-3335838122 so I expect more is needed. I am not even sure if this https://launchpad.net/~b-rad/+archiv…g-archive-extra is in the LE kernel.
I see this as a continuation of this thread [x86-64] WinTV-Nova-S2 USB DVB-S2 Tuner since you are answering chewitt
Martin