Great glad that you got SAT>IP working I didn't realize that TVHeadend would virtualize it as DVB-S like that. It resolves the concern I installing and maintaining a tuner device on LE so is a real plus for having an addon.
petediscrete, how does TVHeadend or the addon deal with needing 3 scan files on 28.2E/F and G?
I assume that you are referring to the LE Setup Wizard: Although I have now abandoned this plan, my original idea was to add a question at the end of the LE Setup Wizard with a menu - 'Install PVR?':
No I was meaning make download.py and settings.xml more automated. https://github.com/LibreELEC/Libr…eadend43/source Also if someone downloads the server you could modify tvheadend43.start to optionally install pvt.hts and then configure the server.
OK I thought this was a generic addon, one more reason not to prompt this during every LE install Why not just merge your addon in the python addon that already exists when the server gets installed?
I still want to test ATSC since it should be similar to DVT-T and I will see how long scanning the outdated upstream frequency list takes and then the EPG scan/update. It is quite long with NextPVR. What do you think would be reasonable for a new user to accept?
Also how would you handle inevitable questions like, it didn't find any/all the channels, the guide is incomplete etc and my tuner wasn't discovered?
DeltaMikeCharlie Rather then messing up the testing thread, I thought I'd reply here
Once tested/vetted/working, what is your opinion of adding it to the LE repository for easy installation by those who want it?For the subset of users with who just plugin a single supported DVB-T card and have a good tuning file PVR could be easy. Otherwise it will take time, know-how for setup and potentially support. Assuming you support TVHeadend via the tvheadend.org forum I don't see any major issue. Once the addon is working support needs to get handed to backend support. Integrating PVR backends could lead to more posts about getting specific tuners h/w and firmware installed and this is already a concern for devices not supported by the kernel. Without a LinuxTV expert one board this could well be an on-going issue.
As always on open source there is a question on what will happen if you decide to stop supporting the addon. edit4ever's excellent work is a case in point.
You do need to support the source on a own GitHub repo though not just a pre-built package. I can submit issue's and PR's there as things mature if I feel that it is worth adding NextPVR support. This will need to wait until the next version though since NextPVR currently doesn't do OTA ATSC (because it is terrible) and DVB-S is under re-development for improvement. I am monitoring upstream dtv-scanning-tables too since outside of the UK upstream conf files they suck.
There is also seems to be a big hole in the uses case for various tuners like SAT>IP, IPTV capture, HDHR devices, pipe devices, CAM/CI, ffmpeg integration and integrating XMLTV and Schedules Direct guide data. Not sure how to limit expectations and what this addon can do, and the differences in PVR on x64 on a full PC and aarch64 devices with an octopus of USB connections.
DeltaMikeCharlie sorry I have unavailable and look forward to testing this, plus later on adding NextPVR as an option. I hope to have a look this week.
I will actual test on CE (I am not an RPi fanboy) and since it is python I don't understand the controversy. You will find even on LE various builds of pythons across the platforms.
I am strongly opposed to this being part of the initial LE setup and the extra prompt will be confusing since h/w PVR is still niche. No doubt some people will figure "why not" and install it without the required knowledge and since a scan can take 15 minutes or more there is a lot to prepare, and understand (scanning, conf files, EPG source that is not OTA).
Also the LE team recommendation has been to install an external backend. Also many LE/CE users have many clients so the prompt can becomes annoying and again some users will install the server when they only want a client.
Since the explanation was that it is a python add-on issue opening overlapping dialogs with no fix in any version of Kodi yet, I think this applies “Insanity is doing the same thing over and over again and expecting different results"
Maybe try another radio add-on , a local m3u or strm file, or a PVR that support IPTV with your URLs.
Your note that the FLIRC USB is not working makes this seem like a USB issue not related to PVR. Did you try USB devices individually in each port and see what lsusb shows.
There are two issues here, one with LE not updating the addon. You don't need to update LE you need to post a link to LE's debug Kodi log.
However if you want to simply check the new version, there is the option in the server addon settings I noted to download the latest version manually. I always recommend newer versions over old but I think your scan problem is really what I posted here. https://forums.nextpvr.com/showthread.php…89618#pid589618
Martin
I am guessing you are using NextPVR and wonder if there is an issue with shared channels on Linux. Scan when the new channel is available and post your zipped logs on the NextPVR forum.
LE should have updated you to 6.1.5 on LE 11 and 12 though. If you need support you would need to update the logs. There is an option to download the latest which is fine to use if LE auto updating fails.
I then tried my Pi 4 for the first time. Kodi works fine, but mpv is slower than ever, which is really strange. It says it's using hardware decoding, but I think it's the display part that's slow.
This may not be anything but I having trouble with mpv and FFmpeg 6 on my Rpi5, I can't get it to detect the odd rpi4_8 and rpi4_10 profiles FFmpeg detects in v5 to enable drm. With FFmpeg 5 this isn't an issue, drm works fine.
It's not a core issue since pvr.nextpvr supports timeshifted radio, but at the same time this is not a LE issue either so it should it be reported in pvr.hts support on the Kodi forum.
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
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
The assumption being is the remote web configuration is done on NextPVR or TVHeadend on any browser. That configuration part wasn't made clear earlier when I said "install"
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
