NextPVR vs TVHeadend

  • vaughng & petediscrete

    I do know what I'm told are the risks, however, there often seems to be limited understanding of the difference between probability and possibility. It is possible I will be hacked but not very probable. Whilst anti-virus and anti-malware are available I'll be sticking with W7, once that changes I may have to review the situation.

    Chrome has already told me it won't update any further and I'm fine with that because I don't use Chrome.

    My approach to a new PC for the past several decades has been wipe, install the OS , remove crud, load any updates I want and turn off auto updates. Its worked with no infections. :)

  • vaughng & petediscrete

    I do know what I'm told are the risks, however, there often seems to be limited understanding of the difference between probability and possibility. It is possible I will be hacked but not very probable. Whilst anti-virus and anti-malware are available I'll be sticking with W7, once that changes I may have to review the situation.

    Chrome has already told me it won't update any further and I'm fine with that because I don't use Chrome.

    My approach to a new PC for the past several decades has been wipe, install the OS , remove crud, load any updates I want and turn off auto updates. Its worked with no infections. :)

    Make sure you give the power supply on that Dell Optiplex a good going over once you receive it. Dell power supplies are notorious for going bad. Plenty of refurbished Dell power supplies at cheap prices on offer but I wouldn’t touch them and new they are not cheap. And keep W7 a million miles away from it. 😂

  • Thanks for your reply, it's great to see a developer's interest to improve his product.

    As there are still some minor DVB-T providers here, the cz-All scan table should contain two sections for every frequency, like this (tested and working for both DVB-T and DVB-T2 providers):

    [CHANNEL]

    DELIVERY_SYSTEM = DVBT

    FREQUENCY = 474000000

    BANDWIDTH_HZ = 8000000

    CODE_RATE_HP = 2/3

    CODE_RATE_LP = NONE

    MODULATION = QAM/64

    TRANSMISSION_MODE = 8K

    GUARD_INTERVAL = 1/8

    HIERARCHY = NONE

    INVERSION = AUTO

    [CHANNEL]

    DELIVERY_SYSTEM = DVBT2

    FREQUENCY = 474000000

    BANDWIDTH_HZ = 8000000

    CODE_RATE_HP = AUTO

    CODE_RATE_LP = AUTO

    MODULATION = QAM/AUTO

    TRANSMISSION_MODE = AUTO

    GUARD_INTERVAL = AUTO

    HIERARCHY = AUTO


    The EPG text has a bad coding in both Kodi & web browser, it's the same and I believe the reason is the ISO-6937 coding is used here (AFAIK) for EPG ( https://en.wikipedia.org/wiki/T.51/ISO/IEC_6937 ) . So instead of local character with diacritics I see two characters - first is a sign of diacritic and second one is an ASCII character.


    I don't use web player, just tested quickly and the primary reason for opening the web interface was a configuration of some NPVR parameters which are not available in Kodi NPVR add-ons settings. Currently I don't need transcoding, I am watching the Live-TV from RPi but a "must have" feature for me is timeshift (to RAM). So I was looking where I need to enable it and surprisingly it's only under Streeaming options - Live TV method - Transcoded submenu in NPVR client add-on. It looks it have to be enabled there and then it's necessary to switch the Live TV method to Timeshift from Transcoded. It's a bit confusing. Now I have the Streaming options - Live TV method in NPVR client set to Timeshift and switching channels works. When playing with this settings, not just NPVR client but even Kodi restarted sometimes. You can look at some recent logs here: http://mysharegadget.com/809460486

    I have experienced the playing was stopped suddenly, maybe it could be visible in the log but I don't remember the time.

    There are issues with timeshift but I am sure Kodi is buggy in this part of functionality - I saw the .ts files created by NPVR in /tmp/ramdisk folder, i could copy them to permanent folder and play using VLC remotely but in Kodi I suddenly could not "rewind" to starting point. I never had such strange and random troubles with timeshift on Windows with several DVB-T applications like on LE/Kodi. This works really bad here and at least Kodi and Tvheadend should be significantly improved in this part, but I see the lowest priority of LiveTV...

    Thanks for sharing details regarding to logs / data area settings, it's helpful.

    In fact I don't know how exactly TVH works with EPG (as previously mentioned, it's buggy and I am sometimes experiencing corrupted items), I think without Internet connection it can't grab EPG despite it should get it OTA. But it works somehow and soon or later I see EPG on all channels.

    With NPVR, so far I don't see EPG on many channels despite the Automatic EPG update was initiated. Maybe I should try to increase the Seconds per freq: parameter. To be tested...

    I still see the streaming interruption (when the Automatic EPG update occurs) as an issue, I understand the reason but there should be any alternative...

    Thanks for your work, I believe NPVR has a potential to be very useful for many users.

  • 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 your quick reply as well.

    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

    This table looks OK but the DVB-T2 items are at the end while DVB-T is obsolete so this should be reflected. I am not sure how tuning works but I believe best option should be to put DVB-T2 and DVB-T sections together with the same frequency, like outlined above ( so the tuning could be perhaps quicker ).

    - 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.

    In this case I believe it was Kodi's bug. I think .ts files were recorded correctly but in Kodi I could (at specific time, when the .ts was about 15 minutes long) rewind about 5 mins back. With TVH sometimes I can get the timeshift point outside of timeshift window. It works quite bad. TVH timeshift also does not work if the option to limit saved timeshift data size is set. This is completely ignored. I would like to see this (working) option in NPVR because the limitation by time is not very good. There are different channels with different stream data rates so you have to limit timeshift for the maximum data rate channels. Thus you can't use the remaining capacity for timeshift when watching channels with low data rate and this is pity. I would just like to configure the ramdisk volume with some capacity and wish NPVR to use it for timeshift data completely (until it's capacity is exhausted) regardless the data rate ( or till the configurable data size limit instead of time limit ). Hopefully this shouldn't be so complex task to add that feature. ;)

    I'll keep testing and provide you with Kodi logs when I encounter an issue recorded there.

    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.

    Yeah when I sent the comments, rebooted LE and then switching channels did not work again (without detail from Kodi)... Then tried the web client to get the error message which was that there's no available tuner (but the tuner device was visible in settings and it's MyGica which was always very reliable, at least in earlier LE versions & Windows). So I believe there could be some issue. I can also try another tuner (Astrometa).

    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.

    OK, this shouldn't be a problem if the full muxes (5 muxes used in my case) can be recorded from LE 12 / 11. I am looking forward for your instructions. Thanks for your effort!

  • 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.

  • 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 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.

    The reason I say this is you are pitting apples against oranges. A closed source commercial product against an open source project. Yes a user of NPVR is free to use it on a personal basis but it is what it is.

    Best starting a fresh thread under the heading NextPVR. Do bear in mind the author is free to join the discussion if he sees it any differently or wants to clarify the situation.