NextPVR vs TVHeadend

  • I should be buying a new machine to run LE/Kodi soon. Up to now I've been running TVHeadend on RPi3. I'm having a look at NextPVR. The configuration certainly seems easier than TVHeadend. I'm just interested in how others percieve the pros and cons of the two systems.

  • I should be buying a new machine to run LE/Kodi soon. Up to now I've been running TVHeadend on RPi3. I'm having a look at NextPVR. The configuration certainly seems easier than TVHeadend. I'm just interested in how others percieve the pros and cons of the two systems.

    Running both (not at the same time though) with full Kodi on Ubuntu 22.04 lts. Setup is certainly a lot simpler on the backend side. Bear in mind it’s running via .Net Core which can be a bit clunky and of course it’s not open source but is regularly developed and updated.

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

  • Thanks for that comprehensive reply. The main reason for asking is the move to a different machine which may end up not running LibreElec (but probably will) and if it doesn't is likely to end up on Windows which TVHeadend doesn't run on.

  • Thanks for that comprehensive reply. The main reason for asking is the move to a different machine which may end up not running LibreElec (but probably will) and if it doesn't is likely to end up on Windows which TVHeadend doesn't run on.

    A dual boot is the obvious solution on any new machine. Linux/Windows for example. You’ll have best of both worlds.

    As I mentioned above both TVH and NPVR work fine on Ubuntu. I’ve Kodi fully launched and working in just under 4 seconds from cold boot on SSD.

    Maybe once you’ve decided on what machine you’re choosing you can revisit your options. Maybe full blown Kodi might better suit your situation.

  • 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

  • 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

    I’m talking about dual boot for someone who comes from a Windows background. Personally I wouldn’t even consider Windows other than the user being more comfortable in that environment.

    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.

    I did state that I run both TVH and NPVR in Linux (Ubuntu to be more precise) on a 24/7 basis with no invasive updates pushed upon you and wouldn’t consider an OS like Windows an option on a personal basis. Way too many obstacles placed in your way.

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

  • Coming from a tech background and still being registered on a number of tech forums I can say that Linux users are generally more evangelical than Windows users.

    Windows users (including me) are generally a) aware of the hellhole they are operating in and b) spend less time playing with the OS itself and so are less concerned about it.

  • Coming from a tech background and still being registered on a number of tech forums I can say that Linux users are generally more evangelical than Windows users.

    Windows users (including me) are generally a) aware of the hellhole they are operating in and b) spend less time playing with the OS itself and so are less concerned about it.

    All I’ll add here is that when your OS tells you that your perfectly good computer is no longer suitable for the next version of it’s OS you’ll scratch your head and look around for an alternative OS.

    You can have the Windows experience without touching the CLI if you choose in Linux. It’s completely up to you which route you choose.

    What I do advise though is to install NPVR and make your own comparison. If you choose to do that again you can do it in Linux or Windows or both if you prefer. From there you can make your side by side comparison between TVH and NPVR. Your observations should be quite interesting.

  • All I’ll add here is that when your OS tells you that your perfectly good computer is no longer suitable for the next version of it’s OS you’ll scratch your head and look around for an alternative OS.

    Not quite - I just continued running W7. I do have one PC dual booting into W10 or W11 so I can test the s/w written on my W7 PC.

  • 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

  • Not quite - I just continued running W7. I do have one PC dual booting into W10 or W11 so I can test the s/w written on my W7 PC.

    Oh dear. Not judging, but I would hope you at least know the risks involved with running Windows 7 in 2023. Especially if you are connected to the internet or regularly transfer files to and from the machine. I too wish I could run Windows 7 without risk. Commenting because I care about your security. I shall not comment further to avoid saturating this thread.

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

    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.

    I could make a list of short comings I found in NPVR but I’ll leave that to yourself or the developer to discover. Straight off the bat there’s no way to add a single mux in NPVR as far as I am aware. Channel change is so slow. EPG from subscription sources.

    I’m always wary of those who arrive to a discussion stating they have no involvement in a product yet are hard selling it. Let the user install it and decide for themselves.


    Not quite - I just continued running W7. I do have one PC dual booting into W10 or W11 so I can test the s/w written on my W7 PC.

    As I said you’re stuck with an OS which could potentially wipe you out and no way of upgrading it.

    I’m assuming you have W7 well sandboxed and nowhere near connected to the outside world because if you think you have problems now. Maybe you like the thrill of a potential hack. It really is low lying fruit for the hacker.

    Immediate advice now is to wipe W7 from anything you have connected to the outside world and count yourself lucky so far. I’m surprised to see someone from a tech/IT background running W7 at this stage. https://www.techadvisor.com/article/744471…-dangerous.html

    Edited once, last by petediscrete: Merged a post created by petediscrete into this post. (June 5, 2023 at 2:34 PM).

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

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

    At first I had to edit the cz-All scan table to add DVBT2 items otherwise only DVB-T channels were found (in our country the move to DVB-T2 occured a couple years ago). Luckily it was easy to find the appropriate table but I had to edit it manually.

    Another issue is with EPG code page which does not reflect national characters and so far I did not find a settings where it could be configured.

    When I played with the timeshift settings, several times the add-on stopped working, sometimes even Kodi restarted.

    The worst issue I am now facing to is that after switching the Live TV channel the error Playback failed is returned in Kodi and Streaming Failed (transcoder exited) when I try to play a channel with web player. Then the nextpvr service needs to be restarted. Sometimes the similar issue happen with a report from web player there's no free tuner (despite it is). Maybe the change of timeshift path to ramdisk could be an issue, I need more time for testing. Nevertheless, it looks the nextpvr service is writing to filesystem (logs?) quite often which is a thing you don't want when booting LE from micro SD card (and so far I did not find a settings to prevent that).

    Another issue is with EPG update (there's a timestamp setting for this) which interrupts the ongoiing LiveTV streaming.

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