Getting Pluto extra to work

[sub]

Does this extra use stdout to feed NextPVR? If so, does it get a "Unexpected error in InputSourceBinaryReader" in the nrecord.log during these adverts?

[mvallevand]

Sub, recordings don't seem to timeout but there is a timeout of some sort on live TV like this.

Code:

2024-05-20 17:07:54.505    [DEBUG][50]    reached end of rolling file. Dropping connection...(2) (available=1128 of=1316)

The gaps vary but could be minutes. However these are fake gaps because streamlink is stripping out ads. When the ads are left in NextPVR gets data but the issue is the video pid for the ads can be different causing issues.

The other issue on multiple video pids is recordings can still contain different video pids in padding or if streamlink doesn't have the ad URL filtered.

Martin

[sub]

Yeah, big gaps are going to be a problem for live tv.

When the adverts are left in, are you able to capture a live tv buffer file when it does one of the transitions?

[mvallevand]

Sure here is the live tv file https://filetransfer.io/data-package/axlABZGG#link

The file didn't stop in the browser but there was a long pause while pids weren't captured, then some more ads instream showed and the finally the next video played.

If you extract 0 0x100-102 you can see the ads that don't display if you play the file.

I expect scte_35 is coming into play, but I don't know how it works.

Martin

[Prsa01]

I will be updating this with the complete/correct info when I next have access to the npvr server. I'm assuming I've missed something obvious, and maybe someone will be able to tell from this remembered info -

After downloading & unzipping the new link at the bottom of the wiki. I execute....

============ from martin
C:\Users\Public\NPVR-Data\scripts\plutotv]python pluto.py install
Generating XMLTV file in C:\Users\Public\NPVR-data\
Found 207 stations
Generating Extra file in C:\Users\Public\NPVR-data\
Filtered 0 stations
Adding extras file to NextPVR
===============

I receive a message similar to "cannot replace existing lineup" (executed as admin). Also, my extra-pluto.xml does not have occurances of "streamlink" in it. I THINK this instruction is shown prior to deleting and recreating pluto channels in npvr but will try doing that to see if that makes a difference.

Thanks

[mvallevand]

Yes this is the issue that I explained, you can't "install" over an existing setup, the API doesn't allow that. Should you want to reset everything use the trashcan to empty the channels from the tuner, otherwise the normal NextPVR process for updating a tuner is required.

You can use the option extra to create a new extra but if it doesn't have streamlink in it something is wrong. Odd that there are 207 stations in the US, there should be more, 207 are what I see here in Canada.

I assume you are trying to test the remux on the fly or streamlink 6.7 Upgrading streamlink is just a different index to the URL so it doesn't improve streaming. Remuxing in post processing is preferred too but it might help on certain stations, it doesn't correct a file.

Martin

[bouilliabai]

Remuxing in post processing is preferred too but it might help on certain stations, it doesn't correct a file.

It does help help, greatly with respect to seeking ability on recordings from certain stations. Not only are the PTS values normalized, giving a valid file duration, but the stream PID's are rewritten to conform to the usual format of video first, while the offset between the video and audio streams is retained.

This is the result of a remux of a recording from the I Love Lucy channel. The default padding of 1 minute pre- and 2 minutes post- was used, for a total of 33 minutes, and it played through in MPC and Kodi just fine, including the Pluto splash screen at the program boundaries. The main issue is that in Kodi, the time is derived from the metadata xml file in NextPVR, which, in turn is derived from the start and end time of the recording. The actual file is 27:31 after commercials are edited out. Attempting to seek past this terminates the playback.

The original recording, edited for clarity.

Code:

[STREAM]
index=0
codec_name=aac
time_base=1/90000
start_pts=90000
start_time=1.000000
duration_ts=3141120
duration=34.901333
[/STREAM]
[STREAM]
index=1
codec_name=h264
time_base=1/90000
start_pts=96000
start_time=1.066667
duration_ts=3150000
duration=35.000000
[/STREAM]
[FORMAT]
nb_streams=2
nb_programs=1
nb_stream_groups=0
format_name=mpegts
start_time=1.000000
duration=35.066667
[/FORMAT]

And the remux, similarly edited.

Code:

[STREAM]
index=0
codec_name=h264
time_base=1/90000
start_pts=132000
start_time=1.466667
duration_ts=148620719
duration=1651.341322
[/STREAM]
[STREAM]
index=1
codec_name=aac
time_base=1/90000
start_pts=126000
start_time=1.400000
duration_ts=148609919
duration=1651.221322
[/STREAM]
[FORMAT]
nb_streams=2
nb_programs=1
nb_stream_groups=0
format_name=mpegts
start_time=1.400000
duration=1651.407989
[/FORMAT]

Seeking in the original is impossible past 0:35 with the aforementioned 2 players. I've also seen cases where the reported time is on the order of tens of hours. Good luck seeking randomly in that.

The attached is what was used to remux the recording. It's streamlined a little bit from the last version, but is functionally the same. Since the PlutoTV Extra device OID isn't fixed, the script needs to be edited to reflect that.

[mvallevand]

I don't now how many times I have to repeat this but we all agree remuxing is generally good. I like to add that it is also not reliable and recording may still be unwatchable or play/skip poorly which is really why this thread started. Users ballfam and Prsa01 have also tried many scenarios including simple remux so I don't want anyone new reading this to think you have found something important beyond the changes in streamlink and guide data length. Also live TV is basically still a complete mess and I wish I knew what ChannelDVR was doing since using the maddox Docker URL's doesn't help for NextPVR or Emby, I can only assume Channels DVR actually handle discontinuities and or SCTE 35.

Device and channel oid are fixed, put there is no mechanism in an extra to update a specific channel, just add new ones. This is why I hope the move in streamlink 6.7 is smart and ID's they use are constant like the slugs used to be. I so I would need to change the addon to map from the slug top _id on the fly.

Martin

[bouilliabai]

Of course I'm not trying to reinvent the wheel here, but only relating my findings in checking various scenarios.

I'd dropped the matter a few weeks ago after trying at least a half a dozen different FFmpeg switches with both the Pluto TV Extra and direct m3u8 access to the streams via extras.xml. Your Streamlink plugin cleans things up considerably, and I compliment you for it. The idea of remuxing in between Streamlink and NextPVR showed a little promise initially, and was certainly worth looking into as well. What remains is recording live TV shows via the extra and remuxing post process if they're to be watched later.

Hopefully a better solution will present itself, but the particulars are way out of my league. I am not a programmer or IT tech by any means, but do have some background in test.

Famous last words... "I was only trying to help."

But that's all beside the main point which was that the extra did not work correctly with recent versions of Streamlink, a rough work-around being suggested. The update from May 16 resolved that elegantly, and a second update fixed a typo and resolved another problem regarding seasons and numbering.

It's all good.

[bouilliabai]

There seems to be a new problem with the timed updates, and with this being a hectic week, I've only just noticed and have no time to dig into it further.

The setup is per the instructions.

Code:

PostStartup.bat contains

Call :LOGMSG NPVR Recording Service STARTED
START /b "" python C:\Users\Public\NPVR-data\scripts\plutotv\pluto.py xmltv-update 180

UpdateEPG.bat contains

Call :LOGMSG EPG Update TRIGGERED
START /b "" python C:\Users\Public\NPVR-data\scripts\plutotv\pluto.py xmltv

PostLoadEPG.bat contains

Call :LOGMSG EPG has been LOADED
START /b "" python C:\Users\Public\NPVR-data\scripts\plutotv\pluto.py xmltv-update 180

The laptop this is running on has been shut down a couple of times this week for heavy storms, and furthermore, is generally put into sleep mode every night. One would expect that on wake-up it sees the missed (default) 2:44 am update from the NextPVR schedule and performs that, then on 3 hour intervals updates the PlutoTV EPG. However, since the last boot, BatchProcessing.log shows the following with the 5/28/24 18:04 update having been triggered manually:

Code:

05/28/24 11:27:57.22 [       PostStartup.bat] NPVR Recording Service STARTED
05/28/24 18:04:33.45 [         UpdateEPG.bat] Logfile is 50370 bytes, maxsize is 64000.
05/28/24 18:04:33.46 [         UpdateEPG.bat] EPG Update TRIGGERED
05/28/24 18:04:43.00 [       PostLoadEPG.bat] EPG has been LOADED
05/28/24 18:05:14.98 [       PostLoadEPG.bat] EPG has been LOADED
05/29/24  9:05:43.77 [         UpdateEPG.bat] Logfile is 50665 bytes, maxsize is 64000.
05/29/24  9:05:43.78 [         UpdateEPG.bat] EPG Update TRIGGERED
05/29/24  9:06:20.80 [       PostLoadEPG.bat] EPG has been LOADED
05/30/24  9:27:55.96 [         UpdateEPG.bat] Logfile is 50892 bytes, maxsize is 64000.
05/30/24  9:27:55.96 [         UpdateEPG.bat] EPG Update TRIGGERED
05/30/24  9:28:50.45 [       PostLoadEPG.bat] EPG has been LOADED