Posts by emveepee

    This is off-topic, but I have often thought that a command line option for the location of the config/data files would also be useful.

    Why would that be needed on LE especially if you are trying to simplify things? For the dtv-scanning-table I didn't use the same approach with the NextPVR server package because I don't think it needs to always part of the package and it doesn't need to download the huge isdb-t folder (we've not had one user) so it is custom. However if there was a separate add-on and it was an optional install I would probably use it and the location wouldn't really manner. Plus the add-on itself would get updates, although I am not as optimistic that users will sub updates to the Linux mailing list. One location for all backend would make it easier to document adding custom conf files.

    It's not TVH, LE now downloads the harder to update repo.

    Hopefully you dynamically create or cache the files the LE plugin downloads for the user. Odd TVH specific key given the relative file is dtv/dvb-t/au-Sutherland

    It's the users getting stuck part that make wizards tough.

    Martin

    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?

    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.

    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

    That's unnecessary, there is no more effort required loading NextPVR then TVHeadend. You may not have set the tuner up in the server. certainly, pvr.nextpvr will not load until the server is running. If you want help you can go to the NextPVR forums and we can help you further https://forums.nextpvr.com

    Just getting the device installed above is just the first step. You still need to pick your scan file, tune your device and assuming the signal is good, pick your channels and set up the EPG.

    Martin

    Instead of TVHeadend perhaps try NextPVR as it can also be installed on LE. It will use the same /dev/dvb tuners as TVHeadend. Schedules Direct integration is built in and fairly easy to configure. You will also get the meta art from SD in Kodi.

    If you do want to this I would recommend adding you Schedules Direct account first. Then do the scan on the first tuner, update the EPG when prompted and then make sure that everything works. Afterward scan the second tuner and copy.

    Note if you are testing setup with the web browser and not Kodi on an Arm device like the RP4 they are not fast enough to transcode North American OTA in real time so video transcoding is disabled LE/CE. Testing in Kodi you will get video. You could enable video transcoding in the server settings to see what I mean.

    Hello, thanks both of you for your reply.

    What is backend :?: ?(

    Thanks for your time and effort.

    Many PVR clients need a backend to do tuning, scheduling, EPG and recording. Please read the Kodi wiki https://kodi.wiki/view/PVR/Backends for more information.

    TVHeadend, NextPVR and VDR backends can be installed on LibreELEC as addons. Here are some CoreELEC documentation links on setting up TVHeadend https://wiki.coreelec.org/coreelec:tvheadend and NextPVR https://wiki.coreelec.org/coreelec:nextpvr. LE will be similar.

    I just got a cheap N100 Chuwi box and wifi seems to work on the nightly (I am using the 2.5G port) but the BT firmware seems to be missing.

    Aug 03 18:58:45 LibreELEC kernel: Bluetooth: hci0: Failed to load Intel firmware file intel/ibt-0040-1050.sfi (-2)

    In the Ubuntu link above someone noted renaming a couple of files in /usr/lib/firmware/intel/ Is there are way to do this in LE?

    Edit: I figured it out, the link above has a different name for the BT firmware this worked

    ls -lt .config/firmware/intel/

    lrwxrwxrwx 1 root root 41 Aug 3 20:12 ibt-0040-1050.ddc -> /usr/lib/firmware/intel/ibt-1040-4150.ddc

    lrwxrwxrwx 1 root root 41 Aug 3 20:12 ibt-0040-1050.sfi -> /usr/lib/firmware/intel/ibt-1040-4150.sfi

    It identifies as the other BT firmware but otherwise seems ok until the proper firmware is available

    Bus 003 Device 002: ID 8087:0026 Intel Corp. AX201 Bluetooth