Ok thanks so without Kodi debug logs I can't help further, I am asking too many questions they would answer.
I will however try and see how h265 timeshifts here on an RPi4 our digital channels are still mpeg2video but I can try and use an HDMI streamer.
Probably not as I don't know what it is and how to use.
Simply using Left and Right buttons on my IR Remote control.
Your second image shows you using the chapter prev button, you need to move focus to the timeline on the light grey sliding scrollback buffer to skip properly. I thought I posted the link from the RPi4 earlier, in ite you can see the I bar cursor moving on the timeline
Out of curiosity are the channels you are having problem with h265 (as shown in that error)? Also sre you switching to and from DVB-T and DVB-T2 on the same tuner?
Here is the error in the dvbv5 front end subsystem. https://git.linuxtv.org/v4l-utils.git/…5/dvb-fe.c#n522 it isn't coming from NextPVR
Are you using the chapter arrows in PVR? They don't seek by time, their seeks are EPG based. I made this video a couple of years ago on an RPi4 with seeking on the timeline not on the arrows, excuse the sound I messed up OBS.
The add-on doesn't really control what the GUI does, it just passes requests to the server.
For clarity the other thread was about the nextpvr service addon and this so far is about pvr.nextpvr addon.
Martin
Might be worth starting a new thread with a relevant title. NextPVR v TVHeadend doesn’t quite reflect what this is developing into.
I agree (probably better on the NextPVR forum where uploading logs is easier) but at the same time there are a lot of TVH and NextPVR feature and issue comparison in these posts that might help other looking at NextPVR. If the OP doesn't mind we can stay here, certainly more on topic the Win7 warning.
I noted there is a PR submitted to have the DVB-T channels removed for the TVH repo.
You would need to post a wishlist post of the forum for the author to optionally allow a size based buffer. I tend not to support that since it could be confusing for users to not really know how much buffer is available. I'd also have to rework pvr.nextpvr.
For timeshifting I did see an seek back on Seznam.cz that had odd range headers for http that is why I would need the Kodi debug logs.
I can't confirm on LE12 but on LE11, I just download the Debian package for libdvbv5 https://packages.debian.org/bullseye/libdvbv5-0 armhf version and extract dvbv5-zap to ~/.kodi/addons/service.nextpvr/nextpvr-bin/DeviceHost/arm32 from there confirm
LD_LIBRARY_PATH=./ ./dvbv5-zap --version
works and then we can continue, if not I will install LE12.
ghtester thanks again. The dtv scan tables can be an issue for many users. The linux source, TVH and crazycat repo's are all different, However from what I can tell both those frequencies should be in the tables that the service downloads https://github.com/tvheadend/dtv-…nd/dvb-t/cz-All
1) pvr.nextpvr comments
- The logs wouldn't show any Kodi crashes, but changing some settings like Transcoding to Timeshifting will require that the addon gets reloaded.
- You have timeshifting set to 25 minutes of buffering so it should be able to rewind to the beginning of the buffer not the show. The actual file might be a little longer but the API restricts it to 25 minutes. I would treat this as an add-on issue though and would need Kodi debug logs.
2) nextpvr server comments
I saw some trouble tuning at the driver level "dvb_fe_set_parms failed" Since I am pretty sure that NextPVR always tunes the same way, I feel that is a driver issue.
The logs also do show the EPG issue which can likely be corrected, the gaps in the EPG could be related too. I think the EIT uses ISO 639
To tackle the EPG problem sub (the author) would need a full mux capture, from the RPi or any other PC you have. I can help you with this if you would like to continue. I could also use the full mux to feed into a modulator here to see if I can duplicate the tuning issue.
Martin
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.
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.
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.
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
