"You can please some of the people all of the time, and you can please all of the people some of the time, but you can't please all of the people all of the time” ..
I don't understand why allowing weak password fit that. User who want strong password would still have the choice. The decision makes no sense to me, just to placate a few users who complain. More weak password users just need to make their opinion felt.
I use an Ubuntu VM machine with 2 processors and 4 GB RAM.
Maybe the x64 build is different?
I needed a lot of RAM to do build LE Monitoring with htop it was hitting over 24GB even with one CPU. so if you don't have enough memory make sure you have lots of swap. I ended up increasing my RAM to 64GB.
Martin
This is the LE forum, why would we test flathub? Your short sample plays on LE 13 nightly for me from the file system but with the SW decoder.
I am using an N100 with LE 12.0.2 (with NextPVR as my PVR service) and I tested HEVC 4k via PVR and don't see any issue playing for maybe 30 minutes (streamed via http).
I do see this logged when it starts streaming before playback but not afterwards, it takes time for my capture device
2025-03-31 10:11:23.014 T:1211 error <general>: ffmpeg[0x39aa1de0]: [hevc] Failed to end picture decode issue: 23 (internal decoding error).
2025-03-31 10:11:23.014 T:1211 error <general>: ffmpeg[0x39aa1de0]: [hevc] hardware accelerator failed to decode pictureSince the OP didn't bother to send LE logs, we are only assuming an x64 VAAPI problem, and it might not even be Intel or if it is which flavour is causing the problem. It also would be nice to know if software decoding works etc.
You don't have to be a developer to do minimum reporting before complaining about Kodi or LE who need thanks not this crap.
In the related post on the issue on this forum from maple, I thought this RE: Irrelevant Kodi Omega (on Ubuntu) post linked to the problem. Given that http streaming might work wouldn't the problem be TVHeadend or pvr.hts and not Kodi (ffmpeg building aside)
Did they tell you what they meant by released? There was a test patch released for their Ubuntu 6.8 mediatree released in January which they might be talking about.
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.
