Thanks for taking time to provide feedback ghtester. The scan tables that I download with the nextpvr service https://github.com/LibreELEC/Libr…ce/addon.py#L34 should be be the same ones that TVHeadend uses. I did suggest to CvH that they should be placed in a common location as opposed to being part of each PVR but that is not available yet.

For the "code page" issue is the data correct in either Kodi(pvr.nextpvr) or the web browser? I am trying to determine where the issue might be. For the OTA guide the character set is in the EIT data and there might be an issue with the utf conversion if both are incorrect.

You absolutely should not be using the web player if it is hosted by the RPi for broadcast TV it is not powerful enough for the on-fly-transcoding. It may not crash the server but the transcoding can no doubt max out the system. There is also about a 15 second lag in web playback before a tuner can be used. Personally, I don't think the web player provides a good PVR experience anyway but I also like using a remote. Some people are mouse/desktop users and use IPTV that doesn't need transcoding or have an x64 device with h/w transcoding and appreciate it.

If you experience issues with playback in pvr.nextpvr when you don't touch the web server I would be interested in seeing the NextPVR logs especially if Kodi is crashing on the raw mpeg ts streams.

The logs level is in config.xml the default is <LogLevel>DEBUG</LogLevel> which is probably correct during the initial testing but you can change it to ERROR at some point. The entire data area, logs, database, channel icon, art etc can also be stored on better storage if you want by editing this line in the service startup https://github.com/LibreELEC/Libr…xtpvr.start#L14

OTA EPG updates are designed to be scheduled daily in off hours when you aren't watching or recording. That could be an advantage for TVHeadend if it never interferes with the broadcasts.

Thanks again for helping out.

Quote from petediscrete

Accept the user’s comments/observations as read. I’m sure others who use/have used TVH for many years and tried NPVR will tell you the same.

My point of asking is to improve the quality of NextPVR they can can certainly opt out. You speak of the advantages of open source but I feel there is an equal opportunity for community involvement of users here. Why do the developers have to do everything on their own? I am in Canada and sub the developer is in NZ so we count on the community from time to time.

Where did I claim to have no involvement with the project? I did say I wrote clients and am the lead contributor for the pvr.nextpvr Kodi plugin. As well I submitted the PR that added the service to LE and have many utilities that make my experience (as well as some others) better. Seriously what is wrong with asking users with years of experience with TVHeadend and hours of experience with NextPVR to ask what can improved?

To your comments users in NextPVR have been creating their own tuning files to add a single mux since I can remember. Channel change speeds can be improved by using the setting to keep digital tuner primed, but I have heard TVHeadend is faster. My experience on digital tuners and HDHR devices here in Canada didn't clearly show a difference, but locally I only have one channel per mux.

I am not sure what you mean by EPG subscription services, but my experience is the Schedules Direct integration in NextPVR is better then in TVHeadend and I know some UK users subscribe to Digiguide. Importing multiple XMLTV files and configuring their download is reasonably easy too and IPTV has direct http XMLTV importing. There probably is something here that I am not aware of.

Quote from ghtester

From my experience on RPi 4b / LE 9 -12:

- Tvheadend is a great product but with some serious bugs which there are for years (timeshift unstable and buggy, EPG corruption, issues with subtitles on version 4.3 ).

- NPVR I am now testing on RPi 4b / LE 12 and unfortunately I have to say it's much worse regarding to functionality/configurability and stability

I would be interested in you expanding on your comments about NextPVR specifically as it relates to functionality of pvr.nextpvr vs pvr.hts and stability of the server (missed recordings and server failures). I believe these are things that can be addressed. Ignore the web server playback since that is not expected to be useful on anything other than IPTV with any Arm devices.

Since NextPVR only records raw mpeg ts streams, does that change anything regarding pvr.nextpvr playback. While Linux support is relatively new and LE support even newer, pvr.nextpvr has been playing these same raw streams from Windows servers for years and we don't often get comments that timeshift is unstable. You may just have poor quality streams, which can easily be tested by creating recordings.

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.