Quote from petediscrete

I’m afraid when it comes to Linux TVH v NPVR is a no contest. TVH wins hands down. . Net Core is clunky and is closed source and while you state that you are somehow privy to the developers API that is not a consideration in TVH. Everyone is free to develop it in any way they see fit.

No I don't have access to the API. What I said is I have requested changes to the API functions I use with pvr.nextpvr and the author has always been responsive to change. The author is also quite willing to make changes to the application modules itself and as you noted new versions are frequent. We are testing on 6.1.4 right now. Closed source doesn't mean that the code is not dynamic.

I am not here to discuss the distinctions and personal biases between open source vs closed source, Linux vs Windows vs macOS, or managed code vs unmanaged code. The author certainly address any limitations in the code if proper support is followed and that is what is import to me and most users, although maybe Windows users are more open to discussion then some Linux users.

A dual boot PVR backend system doesn't make a whole lot of sense to me on x64. A PVR should be running 24/7 or on demand with WOL. One of NextPVR's strengths on Windows power management since tuner driver typically work well after sleep and resume is WOL generally works really well.

Martin

Certainly because TVHeadend as a long history with LibreELEC the biggest benefit might be the support from other TVHeadend users here. However being multi-plaftorm most questions you have will not be LE specific and so you can probably be helped best on the NextPVR forum. Being a NextPVR user since 2006 I am certainly biased but the simplicity of NextPVR doesn't mean that it is any less powerful or stable then TVHeadend.

The biggest weakness I can see in NextPVR would be no bouquet support and support for multi-dec, CAM/CI and softcam would likely be via minisatip. I am in North America and I prefer the support for capture devices like the HDPVR that NextPVR gives me.

Regarding closed source I have also developed several client and utilities for NextPVR over the years and sub has always been able to help me with API calls. In the next version there are improvements to tighten Kodi and NextPVR integration so it is a vibrant project.

NextPVR isn't just a backend though, there are many clients other than Kodi. Client platform has always been a strong point. My username in fact comes from my client work for the Hauppauge MediaMVP. Most users here no doubt like Kodi and while I am the lead contributor for pvr.nextpvr I probably use the native uidroid client on Android more these days for quick PVR use.

The C# vs C/C++ debate can go in both directions, and clunky is not a word I would choose. NextPVR server does use native c++ code for the interface to the DVB subsystem which will be the core of both NextPVR and TVHeadend for digital tuners. C# has the advantage of multiplatform components that don't have have to be custom code, and Microsoft regularly updates the core with enhancements and security patches. I have not heard any complaint about Emby or Jellyfin simply because the are netcore 6 like NextPVR.

Bottom line if you try NextPVR and find something you don't like you can probably get the issue resolved here or on the NextPVR forum. It is worth a look.

As I expected it works fine on LE11 on the RPi 4, I used v then entered 888 as was already suggested.

Martin

I will try on an RPi later today, I suspect it will work, I was showing CE to show you it does work, not to get you to buy a new device.

As I posted my screenshot was from CE so draw your own conclusion.

Martin

As noted subtitle and telextext are different. Here is your sample playing in CE https://imgur.com/a/dP7S3v1 from the teletext option. v then 888 also will work.

Martin

I am not sure it matters but where you using the extracted ova file or the generic image?

Yes AFAIK using streamlink is the best way to stream many streams from plutotv because of the ad break discontinuity. That is how I do it with the NextPVR backend but I haven't tried anything on arm32 so I can speak to the rpi3

In North America the majority of ATSC 1.0 HD ATSC broadcasts are MPEG2/AC3 720p or 1080i.

Martin

Quote from 56knoise

I know the hardware functions as I have this working flawlessly on kodi under windows.

??? Kodi doesn't support the h/w tuners, and TVHeadend doesn't support Windows.

Does it work if you remove the unsupported addons?

There will be some natural confusion on python 3.11 because on Window python is only 3.8.15 and not all Linux versions will be at 3.`11 either so some addons will work OK and some won't.

In this case the issue could have been avoid since the call in question has been deprecated for a long time.

Martin

I still have not found the source for the unofficial LibreElec build on Quartz64a so I cannot do my own build or code review. I feel any discussion on the security of what AMD or Intel might be doing on on the LE x64 platform is rather amusing.

For the Quartza I just had to install it on SD card. You can also try Armbian and see if it works too. I did have to add a missing jumper that my vendor Ameridroid didn't provide.

Martin

Quote from petediscrete

Did you look at Sundtek. One of their development staff is quite active on this forum and reports on Linux support looks quite positive. Just a suggestion.

The X692 is ATSC and even MyGiga don't mention Linux support. I contacted Sundtek about their discontinued ATSC tuner but they didn't respond, I'd still like to get one.

For a bit more context on your ticket I found on Kodi Windows these CC's work in 19.4 but not on the Matrix nigthtlies which equates to the 10.0.2 working and failures on 10.0.3

I reverted this PR https://github.com/xbmc/xbmc/pull/21414 and the file does play closed captioning again.

Martin

If you want to rule out TVHeadend altogether you can install NextPVR Server (available on the LE11 repo under Services). It reads from /dev/dvb too so TVHeadend will need to be stopped Scan, but don't bother with the OTA EPG update for the test.

Martin

In general it would be ok for broadcast, but using s/w decoding is not why I buy nextgen boxes especially as x64 mini PC pricing and aarch64 pricing start to overlap.

I am happy to test the new version. Currently I am using an older Armbian build on SD card and it quite good on Quartz64a so I like to keep the two separate but usable, and I haven't worked out which I prefer. I very much appreciate your work on this platform. I hope you can get an Rock5 B one day.