PVR Setup Quick Start Idea

    I’ve been working on the concept of a PVR Setup Wizard to aid users in configuring a basic PVR using LibreELEC. The idea is that the users will be able to setup a simple PVR from scratch with little effort.

    Bits and pieces of this already exist, however, I’d like to try to consolidate these pieces so that a new user can setup a ‘default PVR’ quickly and easily with LibreELEC out-of-the-box via the Kodi interface.

    I have already built a prototype Python script to do this for Tvheadend. I’d like to hear some options regard the merits of this idea and whether it is worth pursuing for other backends.

    Part One

    Expand the existing LibreELEC setup wizard to ask the user if they want to install a PVR. If the user answers positively, they would continue into the PVR Setup wizard.

    From what I have found, LE seems to have 3 PVR servers that can be run as Kodi addons (NextPVR, Tvheadend and VDR), there may be more, these are just what I have found so far. Furthermore, it seems that only Tvheadend in installed in the LE image. The others needs to be installed from the LE repository.

    I think that the user question would be something like “Which PVR would you like to install?” providing a list of available PVR servers with “None” being the first and default option. Based on this selection, the appropriate Kodi PVR server and client addons will be installed by the existing TVH setup wizard script.

    Part Two

    Each of the LE PVR server addons will be updated with their own setup wizard that will run when first loaded. I have already mostly completed this step for Tvheadend.

    In my TVH wizard, I perform the following steps:

    • Set the TVH GUI language to be the same as the Kodi GUI language, defaulting to ‘eng_GB’ if there is no suitable equivalent.
    • Set the TVH server name to be the same as the LE hostname.
    • Fetch the tuner adapters that TVH has auto-detected and work out which transport (DVB-T, DVB-C, etc) they support.
    • Give the user the choice of ONE of these transports.
    • Based on the selected transport, list the Country and then Region for the pre-defined muxes.
    • Create a new ‘Network’ connected to the adapters of the selected transport and link in the selected pre-defined muxes for the transport/country/region.
    • Perform a scan for services. This is not always successful the first time, so that runs in a loop until all services have an LCN or a timeout is reached.
    • Create a channel for every service.
    • Perform an initial EPG scan.

    I’m thinking of adding an easy way to configure the EPG scan interval too.

    This was very specific to TVH. I suspect that other PVRs will follow a similar logic, but that all of the details will be customised to each PVR’s architecture.

    Running the script on a remote system, I was able to get a virgin LE system (with TVH server and client manually installed for testing purposes), to the stage where the EPG grid in Kodi could be seen populating in real-time as the first EPG scans occurred.

    Thoughts, opinions and comments welcome.

    I have written a few python scripts for NextPVR so it would definitely be doable from localhost since all the web functions can be accessed.

    My opinion is the logic gets complicated really fast when the solution isn't for /dev/dvb tuners that have good tuning source files.

    I am in Canada and don't know for sure, but automation probably works best for DVB-S on Astra 28.2 except for the channel management side. DVB-T would be OK in many places,but in others it would be a real issue.

    ATSC here in North America would also scan well but the OTA EPG is often useless so members so you get into selecting Schedules Direct or XMLTV files or using other grabbers like zap2xml.

    There are also tuner type like the TVHeadend pipe: or NextPVR extra tuners that need more thought. For IPTV as a source that is different logic too. I also don't want to see 10,000+ channels imported without filtering.

    Scripting to install a Silcondust HDHR tuner with guide would be trivial, the question is if you watch this video

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.
    is a wizard really necessary. I have another installer that created that XMLTV file first. My feeling is start with the the EPG from XMLTV or SchedulesDirect if the users doesn't use OTA.

    The other issue is I think it is useful for the user to understand backend configuration for rescanning etc. The forums are full of recommendations to use a dedicated backend which might not be on LE. The same NextPVR web GUI runs on all the platforms so skills gained on LE can be moved to Windows, Linux, macOS etc and the same for TVHeadend and VDR on there

    In the end I am in favour in anything promoting PVR so depending on how

    Martin

    No PVR back-ends are preinstalled in the LE image, all must be installed from the LE add-on repo. It's also possible for users to install Docker and the linuxserver.io repo and run Tvheadend (and likely others) as a container. I would start by creating and proving the wizards to each PVR add-on, and once there's equivalent coverage, tackle hooking that into the first-run wizard.

    Personally I’d concentrate on one single server/backend and aim to integrate it as much as possible with LE. Possibly look at creating a set top box/appliance module experience look and feel.

    You might want to look at spinning up your own community version of LE and put your own stamp on it purely aimed at the PVR enthusiast.

    Maybe include a facility whereby the user could do some basic configuration of the likes of TVH without having to leave the LE environment. In fact I think someone may have already tried that.

    Just my two cents worth.

    Some morning brain farts:

    It would be simple to do a custom LE image aimed at e.g. Tvheadend with more built-in/pre-configured. However the main challenge with DVB is that half the cards users show up with require a non-standard kernel hacked to run with a not-upstream driver so the more appliance-like you make a DVB image, the more limited the audience of users it might work-for becomes. The secondary issue is the inherent diversity of a global audience. LE active-install stats show we have more German (#1), Czech (#3), Spanish (#4) and French (#5) installs than English-speaking US/UK/CA/AU countries combined (#2/#6/#8/#9) so one design danger is assuming the audience and config requirements we see from (English-speaking) forums looks like the one we're most familiar with.

    The add-on from edit4ever might be a good base to work from: https://github.com/edit4ever/script.module.tvh2kodi - the last update was a couple of years ago and Jason hasn't been active around here for a while so it probably needs some work. With my LE hat on: It would be great to have it combined with a setup wizard in our repo to make it more accessible. With my Tvheadend hat on: I don't believe the add-on depends on LE so updating and publishing to the Kodi add-on repo or perhaps to an independent repo that Tvheadend manages would increase the potential audience; albeit at the expense of integration with the LE settings add-on. NB: Tight integration creates the best user experience but typically increases maintenance and if you sense any hesitancy among project maintainers towards integrations; it's because we have an underlying desire to keep things as simple and low-maintenance and sustainable as possible. With that in mind, I suspect a series of good HOWTO guides for the main PVR back-ends in the LE wiki would be a good start for our users.

    CoreELEC has wiki pages for TVHeadend and https://wiki.coreelec.org/coreelec:tvheadend and NextPVR https://wiki.coreelec.org/coreelec:nextpvr Not sure users read these enough based on the questions I get.

    Here in North America Emby, Plex and ChannelsDVR all make their applications more appliance-like by focusing on specific tuners, typically Silicondust HDHR and Hauppauge and offering guide data (using the same data Gracenote provides to Schedules Direct). Just add SAT>IP into the mix and I think LE could do fine job. Sadly, I do anticiapte the appliance devolving into an IPTV pirate recording appliance. I am not saying remove support for other tuners, just make sure the users expectation is lower for other devices.

    Even as TVHeadend under chewitt's new participation will become even more of a focus for LE, I am hoping that there would be an option to use NextPVR if an appliance mode is considered and I would really like to be involved. I already ported edit4evers zap2xml to support both TVHeadend and NextPVR and could likely do the same for the script.

    The appliance probably won't be for the RPi users who make up the bulk of the NextPVR users on LE and CE who only use pvr.nextpvr or KNEWC (an NextPVR GUI on Kodi) since they typically use dedicated servers. I certainly don't want it excluded simply because of lack of exposure to the product. TVHeadend is still best in class and it is great to see it getting more life, but it still is Linux only.

    The strength of the RPI and similar boards is the potential for them to be used on an embedded OS basis. They are the nearest thing to a bare bone purpose built set top box you will find.

    I’m not a big fan of tinkering but I put a Rock64 into an old analogue DVBS receiver case along with an SSD drive and DVBS tuner, installed the community version of LE, TVH server and client and it boots quicker than some of today’s domestic STB receivers.

    Remote is very usable by all in the household and of course we don’t need to wait on the manufacturer to issue a firmware update if we need to make changes.

    Again that was just a noodling session to see what it would look and perform like in the real world. That’s why I suggested the appliance model approach. It may be a vertical market approach but who knows what you could create with a little imagination.

    Thanks to everyone who provided feedback.

    At the start of this process, I did have a vague recollection of a Kodi addon to manage TVH. I remember having installed it once, but for reasons that I can not remember, I uninstalled it and went on with my life.

    I tried to install tvh2kodi again yesterday, but it crashed because of a deprecated Kodi function. It seems that it has been updated for Matrix, but not Nexus. tvh2kodi claims to have a setup wizard, so if that can be made to work then I need not continue with my idea.

    I took a quick look into the tvh2kodi bugs and I fixed several problems. However, every problem I fixed just uncovered a new one until it lead to a problem with an external dependency so I stopped there. I think that tvh2kodi needs some remediation to get it working again.

    Unless the ‘PVR Setup Wizard’ is either part of, or run from, the LE ‘First Run Wizard’, then its value to end users is reduced. If the user needs to finish the LE wizard and then load a Kodi addon manually, they may as well just load the PVR back/front-ends of their choice manually and get on with their day. I have no interest in creating an LE fork just for that.

    I need to reconsider my approach. If tvh2kodi can be revived, then that is my referred option as it already has the functionality that I proposed for the TVH part. Perhaps it can be modified to detect that it is running on an LE system and adapt accordingly, or, perhaps if there ever is an LE ‘PVR Wizard’ then it can call the tvh2kodi wizard with a parameter.

    I managed to clear all the bugs that were stopping me from running the tvh2kodi DVB-T Wizard (there may be other unrelated bugs). Here are the steps that the wizard takes:

    • Start Wizard
    • (Are you sure?)
    • Select a single tuner
    • Select location mux list
    • (Full scan plus progress)
    • (Report on number of channels created with a message “You can now enable additional tuners in the adapters menu”)

    In addition to this, the Wizard silently created ‘Channel Tags’ within TVH for HD, SD, TV & Radio channels.

    What follows is a comparison, not really a critique per se:

    It only configures a single adapter. If you have multiple adapters servicing the same transport, the others will need to be enabled manually or have the Wizard run a second time. My wizard grouped the adapters by protocol and processed all of the adapters in that group.

    The UI language is not set in TVH based on the Kodi language. TVH remains as English. Some of the Kodi dialogue boxes are localised, however, the vast majority of the addon is in English, hard-coded in the scripts.

    The TVH server name is not set. This is not really a big deal though.

    The muxes are presented in a single 1119 item list not separated by country. Great for me in Australia, not so great for people in Vietnam. My wizard was going to group be country and then region.

    My wizard did not yet create channel tags, however, I was planning to create tags by provider name.

    At the mux selection stage, the 'Cancel' button does nothing. The Wizard just keeps going.

    Quote from emveepee

    Even as TVHeadend under chewitt's new participation will become even more of a focus for LE, I am hoping that there would be an option to use NextPVR if an appliance mode is considered and I would really like to be involved.

    I have an interest in both projects, but I have no interest in forcing either project on the other. If LE decides to do or allow more with PVR then it will always be a team decision; but one that's ultimately driven by people showing up on GitHub with some quality pull requests to add the required changes. We (maintainers) are risk averse and will want to have a clear vision for how things will look and work - at both user-storyboard and code levels. Please also understand that LE has history with new-ish people showing up and trying to push poorly considered changes into our codebase (our indigestion on the experience and their intollerance resulted in CE) and there's a current and live example unfolding in Team Kodi at the moment with a well intended feature impacting a release cycle and needing a massive group effort to fixup code that (with the benefit of hindsight) shouldn't have been merged so quickly.

    DeltaMikeCharlie I'll ping Jason offline to see if he has any plans for the add-on, but if it's unmaintained for two years we prob. already have an answer. You don't have to reuse it, but if it's already a reasonable match for where you wanted to go with things adapting prior art is often faster than writing from scratch. Your call entirely.

    I have been thinking about the architecture and specifically, how may addons are required and what their function will be. My thoughts are as follows:

    1) Existing LE First-Run Wizard
    2) Central PVR Wizard, responsible for asking ‘Which PVR’
    3) Individual customised wizards for each PVR.

    My initial thought was to have 2) above incorporated into 1), however, I perceive reluctance to change this in a major way.

    Having a separate central PVR Wizard will also allow users to revisit the decision should they choose to do so. It may also allow them to uninstall a PVR should they choose.

    The central wizard will be data-based. That is, the selection of available PVRs will not be hard-coded. IT will be provided in a configuration file or read directly from the LE addon repository.

    Regardless of the availability of a step-by-step wizard for a particular PVR, the bare minimum function would be to load the PVR server and the PVR client addons. For example ‘service.tvheadend42’ and ‘pvr.hts’ for TVH.

    For PVRs without a step-by-step wizard, perhaps a ‘what to do next’ window could be displayed.

    Attached are my thoughts on the workflow layout. Colours, text, icons, etc, yet to be determined.

    I’ve often noticed that group think can cause push back to change. The “well that’s the way it’s done here” thinking tends to discourage skilled new comers.

    I’ve seen the work you’ve done in TVH so far and clearly your thought processes are of the lateral variety. Always welcome in this area.

    Bearing in mind that you’re trying to make life easier for the standard user who just wants to install, watch and listen you’re definitely on the right track.

    The TVH UI isn’t the most friendliest of environments so if you can create an add on that can enable the user to configure a PVR with the minimum of fuss and interaction with the TVH UI I reckon you’re half way there. You’re definitely on the right track though so far.

    I’d definitely concentrate on TVH and it’s integration with Kodi and it’s derivatives via a credible add on for PVR purposes. Do bear in mind that TVH is a standalone project in it’s own right and stands up on it’s own too and could definitely benefit from your ongoing input too.

    Good, start.

    I still think EPG needs to be right after "transport", sure you can have TV without it but it is not PVR. People need to think about this right from the beginning, IPTV user are used to them being in parallel.

    Transport is a bit technical too, maybe "Tuner Type". I don't consider SAT>IP a transport. Same for the Silicondust devices which are the most popular here.

    Country and region are DVB-T/T2 and DVB-C related, so need to be optional. The pick lists do need to be based on the new standard for LE https://git.linuxtv.org/dtv-scan-tables.git/ good or bad to avoid maintenance of the wizard. The hardest part is where does a user who can't find their country, city or the scanning table is crap go for help?

    petediscrete - Thank you for your kind words.

    I do not intent to abandon TVH and I have a list of potential improvements on my todo list. I just like some variety from time to time.

    I also have a number of Kodi PRs that are on hold until the current release cycle is finalised. Once the next Kodi release is open for development, I will give those some more attention.

    I do realise that TVH is a stand-alone project unrelated to LE. However, LE also has a Kodi binary addon that neatly packages a TVH installation. My primary objective would be to get DVB-T working and then see where that leads to.

    I only have access to a DVB-T system. In order to test DVB-C and DVB-S systems, I will have to rely on the kindness of forum members to provide feedback. When it comes to ATSC, IPTV and other transports, that may be a task for developers with better and/or region-specific knowledge.

    I still would like to see what happens with tvh2kodi before getting too carried away.

    I’ll gladly help you with DVBS. Don’t use DVBT and DVBC. Nothing worth receiving here on the network. IPTV is such a grey area and wouldn’t be one of TVHs great strengths. Keep up the good work either way.

    emveepee - ‘Tuner Type’ is a good suggestion, especially when it comes to localisation because ‘transport’ could also mean bus, train, etc. Thanks.

    The big box to the right of the screen is a flexible space. Perhaps Country and Region could be combined into that space with Country being a dropdown and Region being a list box populated based on the country selected.

    I use the TVH API to determine country and region:

    }, {
        "key": "dvb-t/au/dvb-t_au-Sutherland",
        "val": "Australia: au-Sutherland"
    }, {

        "key": "dvb-t/au/dvb-t_au-Sydney",
        "val": "Australia: au-Sydney"
    }, { . . . . . . 

        "key": "dvb-t/se/dvb-t_se-Sundsvall_S_Stadsberget",
        "val": "Sweden: se-Sundsvall_S_Stadsberget"
    }, {

    If TVH is updated to use the new scan tables then the wizard may need to be reviewed.

    If the scan tables are incorrect or absent, then the user will need to perform a manual configuration directly in TVH unfortunately. As I am basing my wizard on the scan tables that TVH knows about, then the user would probably be stuck unless they know their local frequencies, etc.

    I will freely admit that IPTV is a big blind spot for me. We do have an IPTV service in our house, but it is part of a proprietary set-top-box provided by our ISP. Perhaps if ‘IPTV’ is selected as the tuner type then the Country/Region button/s can be named to something else and the flexible area updated accordingly.