Those are the frequencies working in Australia with NextPVR's tuning files for Windows DVB and also SAT>IP with forced 7Mhz wide spacing. We have found auto wasn't working well with all tuners.
Worldwide everyone agrees the Linux dtv-scanning-tables suck and the fact that they need to be submitted via the Linux media mailing list sure doesn't help users.
Windows 10 and 11 include SSH client and server. https://learn.microsoft.com/en-us/windows/…l/tutorials/ssh
I think it is explained here https://github.com/arnesongit/inp…direct-binaries
Although I agree most IPTV and all PVR VOD I see on the various Kodi related forums are pirated, the legitimacy of streaming non-DRM'd URL's from the slyguy site or the the Samsung links is open to debate. Most "official" media streaming Kodi addons fail that test.
The main reason that that slyguy URLs fail would be they are often geo-locked. There are also some that have more than one video stream or multiple programs in the PMT which aren't supported by most players. If you want help with NextPVR go to the NextPVR forum. The author happens to live in NZ too which might help
Otherwise random URL's you find on GitHub just cannot be considered reliable enough for PVR.
Out of curiosity why did you decide to go ITX form-factor and not just buy one of the many sub $200 N97 or N100 boxes?
Martin
That is expected behaviour for joined episodes in one file.
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.
