This is everywhere the same root cause. The hardware isn't identified because of a new identifier.
It is a new identifier but it is also new internal h/w if you follow this parallel thread [x86-64] WinTV-Nova-S2 USB DVB-S2 Tuner I guess the good news is there is a potential for a kernel patch https://launchpad.net/~b-rad/+archiv…g-archive-extra eventually.
The exact name on the device is "WinTV-Nova-S2" and is not listed on the LinuxTV Hauppauge Wiki. It was bought back in December so is "New".
Windows automatically downloaded the Hauppauge driver describing it also as a PCTV 461e. The NextPVR server recognises it as a "PCTV 292 e/461e BDA 28179 TV Tuner S"
I dont want to abandon my LibreElec server for a a Windows server just to be able to use this USB DVB-S2 tuner. I will contact Hauppauge Support to see what they say.
If you read the b-rad issues on GitHub (best place for Hauppauge Linux support) you will see that Hauppauge marke the Pinnacle 461 (as shown on your Windows BDA driver) branded as a Nova S2 type 3 which isn't supported in Linux.
When I see this "EPG Update complete. [0 inserted, 0 updated, 238 skipped]" it seems that
1) the source is not very complete, typically PVR will have more than 238 shows but it shows that the guide is being updated.
2) your XMLTV file is stale. Typically this happens when you point to a local file that you aren't updating correctly. If it is online your source is probably just bad. It could also mean that the guide data matches the m3u file.
Feel free to post your zipped NextPVR logs on the NextPVR forum and we can have a look.
Why are you sharing all the documents on the NAS with one username and password if you are so worried about visitors? Limit the source to the media that they can view with the remote.
With physical access to the LibreElec file system the encryption is useless because you could just install a version of Kodi to log the user name and password, or copy the file and decrypt it elsewhere.
Don't make LE visible to your network. This is no different than any Kodi installation if you have access to the filesystem you can access passwords.xml so not LE specific.
TVHeadend and NextPVR can both create a channel from a pipe if you want to test a file as true live TV.
I used this patch as a model for building for the TBS5530 which works for me with the LE 13 nightly kernel 6.12.5 and I kept the TBS5020se diff in as an aide and it didn't give any errors. For my build I did have to add a line "default m if MEDIA_SUBDRV_AUTOSELECT" to the dvb-usb/Kconfig for the drivers because the default for kernel_make was N not m so the =m was being overwritten by package.mk
As I posted I tried -DLLVM_PARALLEL_LINK_JOBS=1 (in common) and still need `16GB and 8GB swap. Adding -DLLVM_PARALLEL_COMPILE_JOBS=1 didn't making any difference. After adding the swap it worked so I tried the default package it still worked and the memory and swap usage were similar.
Even with all LINK and COMPILE runs set to 1, it is slower but eventually there is a task that overpowers the CPU until the out of memory sig 9.
dmesg shows 14 task for llvm-tblgen on 14 threads the time of the crash. Thinking about that I noticed I didn't have llvm installed, and I seem to be able to build this now. It could just be memory too, since upping my swap space also seems to help. 16G + 2G doesn't work but adding 8G of swap seemed to do it.
I just had the same issue with building llvm on LE 13. When I issue scripts/build llvm directly all 16 threads max out at 100%, all 16GB RAM is used and l swap is 100% and I have to wait for a sig 9 on all threads to use the PC. I will try later the the the link and compile jobs set to 1.
To mount a nfs4 server use e.g. disk=NFS=172.16.3.4:/mnt/media/storage,vers=4.2
As a test you may even try with disk=NFS=172.16.3.4:/mnt/media/storage,vers=3 to see if there is any issue in the LE parsing code.
So trying the test it works with vers=4.2 but fails with vers=3 Here is the working log FWIW https://paste.libreelec.tv/flowing-mullet.log
Thanks both of you.
OK, I did try vers=3 from the command line and that failed but I will try the other options
mount -t nfs 172.16.3.4:/mnt/media/storage/$OVERLAY_DIR /storage -o rw,noatime,vers=3Martin
I am pretty sure the change has something to do with nfs4. I can't specify disk=NFS4 as a kernel parameter as far as I can tell but I have been able to use /flash/mount-storage-sh to manually mount /storage
OVERLAY_DIR=$(cat /sys/class/net/eth0/address | tr -d :)
mount -t nfs4 172.16.3.4:/mnt/media/storage/$OVERLAY_DIR /storage -o rw,noatimeIt seems like the busybox mount that is used at this early stage before the full mount.nfs etc is available is not good at working with nfs versions
Ok remounting rw does work which allows me to start Kod and I have this log now https://paste.libreelec.tv/clever-wolf.log so maybe related to
Dec 17 19:59:29.015980 172.16.3.29 kernel: Kernel command line: root=/dev/ram0 rdinit=/init usbcore.autosuspend=-1 BOOT_IMAGE=/KERNEL ip=dhcp boot=NFS=172.16.3.4:/srv/tftp disk=NFS=172.16.3.4:/mnt/media/storage overlay systemd.debug_shell
Dec 17 19:59:29.015991 172.16.3.29 kernel: Unknown kernel command line parameters "overlay BOOT_IMAGE=/KERNEL boot=NFS=172.16.3.4:/srv/tftp disk=NFS=172.16.3.4:/mnt/media/storage", will be passed to user space.I looked for a tmpfiles.d that might be missed but I don't see anything around Dec 6.
Assuming you are using Generic (GBM) this is usually caused by kodi crashing. If ssh is enabled login should still be possible. With adding systemd.debug_shell to the kernel command line a debug shell can be reached at console 3 with Alt-F3 as long kodi is not running.
If you are using the overlay parameter the message is caused by this mkdir. Please check the access rights of 172.16.3.4:/mnt/media/storage
Yes it is Generic. If I drop KERNEL/SYSTEM back to the LE 12 or LE `13 before Dec 6th the mkdir works so what access right would have changed?
Thanks though I now can drop to the shell with ALT-F3 and can see that when it works mount has
172.16.3.4:/mnt/media/storage/1002b58608ea on /storage type nfs (rw,noatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.16.3.4,mountvers=3,mountproto=tcp,local_lock=all,addr=172.16.3.4)and in the newest version the line is the same but that rw turns to ro but I can see existing files.
I PXE boot one of my machines Radka X4 (Intel n100) and I recently updated it and and it fails to load. Going back in the nigthlies PXI boots appears to have stopped working for me with the Dec 6. I can't see all the FAILED services on boot but it hangs at Reache dtarget kodi.target and freezes Any suggestion how I might diagnose this?
I did trying renaming my system based storage though and it doesn't recreate it instead I get an error during boot
writer can't create directory '/storage/the number': Read onlyfile system
Error in mount_storage: mount command could not mount 172.16.3.4:/mnt/media/storage/same number
On LE 12 I didn't update to v7 yet because I typically wait for the initial release to settle and the Windows part of the update has taken a bit of time to debug. 7.0.1 will be worth it for UK users since it grabs the OpenTV EPG too.
However scanning files for Linux aren't included and the Linux dtv scanning conf files are crap though so if you need help I can generate them. You can try this one and see how it goes. NextTime post on the NextPVR forum,
/home/.kodi/addons/service.nextpvr/dtv-scan-tables/dvb-s
Martin
Thanks for that. I guess there could be a related issue if the audio PIDs increase or in the Swedish case you noted more video PIDs. I'd love to get a full mux from Sweden when the regional news is plays to send to my demodulator.