Posts by emveepee

ghtester I was just checking why fullmux642 (with Nova) was not working here and I found that it has 2.89% transport errors. with zero in the others (using tsduck). This could explain why you aren't getting guide data for channels like Nova. Also as I noted NextPVR works with raw ts streams and sends them as-is to Kodi. TVHeadend I believe remuxes them and it is possible that this can help but that it not an insignificant error rate.

Quote from petediscrete

Sorry to interrupt and hate to burst your bubble but Kodi is THE primary client here. If you want adoption on LE you’ll need to take that onboard. You really should invite the author to join this discussion as I suggested before.

Pleases stop trolling me. I am quite onboard with the Kodi client I told you I am the primary maintainer of pvr.nextpvr and ksooo has been helping me out by adding some features that make the pvr.nextpvr integration better. The author is aware of this thread and he (like I am) are interested in helping all our users and all priorities. There are a lot of users running Kodi on Windows with Windows backends too.

The channel numbers in NextPVR can be whatever you want assuming you ignore Kodi's odd default to use Kodi numbering.

it looks you have two NOVA and nova. nova on 35 is the one on 498 showing as NOVA here. I am having trouble getting nova on 642 to scan, sub can scan it, his tuners are going to be better than mine.

Regarding your last comments features in NextPVR need to work in Windows and Linux. Tuning is faster in TVHeadend for digital tuner, I would expect 1 or 2 second tuning in NextPVR for digital tuners. The prime focus in NextPVR is on portability and typically recording not, on Live TV, has been the main user focus. Now with 100's of channels people tend not to zap between channels anyway.

However my experience is Kodi users do use Live TV a lot. I would expect pvr.hts to be integrated better since the maintainer is also the main developer for Kodi core..

Note too that the primary client for NextPVR is not Kodi.

I add your 490 fullmux and I don't have any problems with NOVA. https://imgur.com/a/nTEOQXd Do you know any channels that don't provide data that should?

I think sub got it to work, Kodi channel 6 is xmltv but OTA looks better now https://imgur.com/a/99TrRBZ Thanks for providing the full mux streams.

The data screen is not supported in either pvr.nextpvr or the API to the backend. never saw the point to implementing providers as it is mainly cosmetic. The signal strength info can be of value but only for digital tuners and is not multi-platform and is sometimes incorrect. I know when my signal is bad by watching but no doubt technical users who are used to it will miss it.

Watching TV and doing an EPG update is not supported and will cause issues. If you must do it issue a pkill DeviceHostLinux in PostUpdateEPG.sh

NextPVR logs would tell us why only on frequency is being scanned.

The EPG issue is known for sure, as I said sub is looking looking into it, and making progress

Thanks, my system is totally fake streaming from your fullmux in a loop as dvb-t but this test is on an lesser machine than an RPi4 (CE20 S905X4 with the Sony tuner on Astrometa) but I can't get tuning to fail https://imgur.com/a/IdE7s2d (you need to enable sound on imgur) Does tuning work on the same mux for you? If not I might need to try the same test on an RPi4, since your messages appear to be kernel related.

Note in the video I did import one channel using XMLTV to get proper text. Sub is looking into your problem and if you want to use XMLTV I can help you out there in the meantime.

Thanks ghtester you certainly went above and beyond. I will make sure that sub can access them too. Can you also provide /storage/.kodi/userdata/addon_data/service.nextpvr/config/adapter0-DVB-T-channels.conf it might help with some utilities I have.

Regarding that test, did you have have any issues running the different zaps? If not then maybe the NextPVR initialization can be improved. I do see a warning output buffer overrun after 36.11 seconds which

7. Most wireless RF remotes are USB HID compatible and many have a keyboard if you need that too. No need for a FLIRC unless you want IR, since RF is better anyway and doesn't depend on line of sight.

My favourite with the keyboard is the AuviPal G9S backlite, programmable keys for the TV and rechargeable batteries. Another choice would be the G20BTS since it is IR, RF and Bluetooth but it eats batteries.

Martin

Sorry, I didn't know that libdvbv5 was included with LE, being in /usr/bin I think means it is in the baseline. In any case I am happy to see that you found 1.24.1 since you can try other tests. Plus it includes a PR I submitted that was causing scans to fail here in North America.

The syntax for the full mux capture is below You will need to find a host for the 200MB ts files that get created.

dvbv5-zap -c /storage/.kodi/userdata/addon_data/service.nextpvr/config/adapter0-frontend1-DVB-T-channels.conf  Prima\ Max -P -t 60 -o fullmux.ts

You can use any channel name in the mux. It might be good to try CT 2 HD T2 as well. If it is easier any channel on those frequencies will do and you don't need to worry about the space. I don't think my demodulator supports DVB-T2 so I am not sure I can try the channel change issue but sub might be able to check that when he looks into the EPG issue.

You would need restart the NextPVR service if it has opened the tuner.

The other test you can do is backup /storage/.kodi/addons/service.nextpvr/nextpvr-bin/DeviceHost/arm32/libdvbv5.so.0 and copy in the new version from 1.24.1 that you found. It won't help with the EPG but it might help the tuning issue.

The Kodi log does not have debug logging before the dvb_fe_set_parms failed stopped playback so I can't see the skip information.

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.

Quote from ghtester

---

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

Quote from petediscrete

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.

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.