Was just doing some screen grabs for Graham for setting up a colossus for the wiki and I noticed a weird glitch.
Hopefully the marked screens below explain graphically what I am seeing when I open the Devices screen, then navigate around in it.
The xml output of NScriptHelper is not working for me for batch files, so I thought I'd write my own helper (in Python) for the few commands I need. I've got it working, initiate a session, login (thanks to Martins example). However I'm confused as to what format the startTime field is in so I can convert it to a printable date.
Currently NextPVR names files of recordings without season/episode data as such "title_yyyymmdd_xxxxyyyy.ts." Plex does not recognize these files and if you would just change the date format to comply to Plex standards as below, or make it an option, that would be a BIG help.
The date can use either the YYYY-MM-DD or DD-MM-YYYY formats and can use different separators:
i currently have the latest V4 installed (actually i have it installed side by side with 5, so i can send a full channel list to some TV's in my house and a list with just kids channels to the TV's my kids in bedrooms)
i am using Kodi on CoreELEC as front end.
I have two providers for ITPV. i manage the m3u through online m3u-editor that syncs with my providers daily and allows me to merge the lists from both providers, make custom groups, arrange group and channel order, set custom Logos, and map EPG, and I then get my fixed up combined m3u from m3u-Editors configurable url.
I cant seem to get this to work in nextPVR when accessing from Kodi. When i import the m3u, it numbers the channels that appear first in the m3u starting at number 1 ascending, then when it gets to the first line in the m3u that is from my second provider, that has a different streaming location, instead of numbering the channel incrementally 1 higher than the previous channel from my first provider in m3u, it starts again at 1. All looks OK apart from that on the PC and all channels work in the client app on my PC, but the Kodi plugin will not load any channels with the below error (repeating many times for all channels / groups)
ERROR: cb_transfer_channel_group_member: Cannot find group 'IPT USA Movie Networks' or channel '28010'
If i separate out the providers with a url for each in m3u-editor, both work fine on their own and load in Kodi, but never when both are loaded at the same time, regardless to weather i load as a url with both providers combined, or are separate url for each provider doing two imports on my device, or as a combined m3u on my PC or two separate m3u from my PC. i am able to load the combined m3u from both file and url without issue in simple IPTV client, and it also loads in V5, but V5 re-sorts my group order alphabetically rather than the order i configured in m3u, with no option i can see to alter group order from alphabetical, and V5 only downloads a handful of the channel icons, .vs all channel logos downloaded in V4.
i managed to get a bit of a workaround by exporting the channels after import to xml, then deleting the device, setting up a new device and importing from xml rather than m3u, or url providing m3u. this worked and all the channels loaded in Kodi from both providers at the same time, but i lost all my groups, and as soon as i placed channels in to groups with nextpvr.exe, kodi failed to load again with the same error about not being able to find group or channel.
has anyone faced similar issue before? is there something i can do to get past it?
Does it means that record features while watching channel is not yet implemented on this version ? Or do I have to upgrade to last Kodi version ?
By the way, Npvr plugin ion Kodi side is up todate
I noticed this feature is anot available from Npvr web app.
Over the past week or so I've had a couple comments on various threads I started saying that it'd be welcome if I "contributed to the wiki," but it's not super clear which wiki I should contribute to, and it's not super easy to make the commits.
First, which wiki do you want contributions to? There's the one on sub's github repo, https://github.com/sub3/NextPVR/wiki, and there's https://nextpvr.com/nwiki/pmwiki.php . Do ... do you want to maintain 2 wiki's for the same project? That sounds awful :-p. Yes, I'm offering my help here to consolidate the two.
Second, can you clean up your header links? On forums.nextpvr.com the Header link to "Wiki" points to https://github.com/sub3/NextPVR/wiki, but if you've somehow found yourself on https://nextpvr.com/nwiki/pmwiki.php, the header link to "Wiki" points to http://nextpvr.com/v4wiki/pmwiki.php, which is a broken link. Yes I'm offering help with that too, though I suspect you wouldn't want to give me the kind of access that'd require.
And last ... on https://github.com/sub3/NextPVR you say "create a github account, then PM me on the NextPVR forums (my account name is 'sub') , letting me know your github account name. I'll then add you to the list of collaborators with access to this repository." Ok, I can do that -- I would be more comfortable, at least initially, forking your repo and making pull requests, so you can look over my changes and approve/reject them ... maybe after a couple of submits that way I would feel like I deserved a place as a "contributor" on your repo. I suspect that I'm not the only one who has felt this way, and this has blocked more than one person from making a "small" change to the wiki. It's intimidating to have to PM sub for a 2-line wording change!
Following the evolution of Teletext, the next standard that seems to have emerged and adopted by free to air TV is HbbTV.
Given that for a PVR server most likely the requirement to support this standard would be somehow simple as described in the below
TVheadend thread: https://tvheadend.org/issues/1711
"The HBB TV data is simply data PIDs linked to the channel in question. It's a table called AIT, and the data is a format called DSM-CC. I don't think TVHeadend would have to do anything other than not filter out the AIT data PIDs (it does currently, even in a raw stream of a channel without "/play" in the URL). Then the data would be available for processing by some kind of plug-in on the client side (Kodi via HTSP, etc.) I guess this is how teletext works currently? For an example, I've attached a full mux TS dump of 11494H from Astra 1 19.2°E. This carries German ARD channels, and they all have PIDs carrying the HBBTV data. For example, Das Erste HD has HBBTV data on PID 1170, and then some more on PID 2171 (not sure what this latter one is for). Looking at the data in PID 1170, it's carrying the URLs for the HBBTV service, for the HBBTV plugin on the receiver to receive the content from. PID2171 may be some of the data for offline viewing (I don't know). I found a plugin for Firefox called FireHbbTV - with this installed, if you visit one of the URLs shown in the PID 1170 stream - http://itv.ard.de/ardstart/ You see the data that gets fetched, as if it were on a TV or receiver that supports HBBTV. On the face of it, all I think TVHeadend needs to do is pass through any data PIDs marked as carrying HBBTV data!"
Is there something that NextPR can do and possibly go one step further and even expose somehow these PIDs also in the web client so that if somebody for instance uses an HbbTV emulator addon like for instance this one for Chrome (and Chromium Edge): https://chrome.google.com/webstore/detai...ated?hl=en can use it?
I miss the option to use an UNC path to the recordings location.
That's important to host the recordings on a different system and
is possible with the old Version 4.
logs-20200423-0755.zip (Size: 1.11 MB / Downloads: 2)
Hi, While server is running it constantly says {236} Unexpected error in HTTP input sourceystem.net.webeception:The remote server returned an error (403) forbidden. I am a newbie and im guessing it is password issue but i recently unsed epg buddy 0.5.0.8 and removed it and used schedules direct assigning each channel individually which has been working out good I have included my logs. Also getting one other error {9} writer.close() did not complete in a timely fashion.