We’ve rolled out an update that should make it behave better when exporting an m3u with HLS from one DVR to another. There shouldn’t be any change for TVE, but if there are any problem, please let us know.
1 Like
After updating to v2023.05.16.1823 getting this log error on many TVE channels using both of my providers. ESPN networks and TV Land as examples. Reverted back to v2023.05.15.1555 and all is well. Possible bug?
From Apple TV (Shows EOF on screen of TV)
Error during live stream for ch6140 ESPN1: astits: PCR PID invalid
Error during live stream for ch6020 TVLAND: astits: PCR PID invalid
or from web
ffmpeg: ch6140-dANY-ip192.168.1.30-remux: Output file #0 does not contain any stream
I don't use the Rewriter, but I'm also getting EOF for several channels on Apple TV with ...astits: PCR PID invalid error following the update.
I don't have the Experimental Rewriter enabled either. Just tested by streaming and recording Discovery, then updating from v2023.05.12.1543 to v2023.05.16.1823
Playing live or recording now fails
2023/05/16 18:00:47.767448 [TVE] stream timestamps: discovery: start_at=2023-05-16T17:59:47-07:00 end_at=2023-05-16T18:00:16-07:00 live_delay=27.309440846s
2023/05/16 18:00:47.767655 [TNR] Opened connection to TVE-Comcast_SSO for ch6101 DISCOVERY
2023/05/16 18:00:47.767780 [DVR] Recording for job 1684285045-ch6101 from TVE-Comcast_SSO ch6101 into "TV/Deadliest Catch/Deadliest Catch S19E05 In Need of Rescue 2023-05-16-1757.mpg" for 12.996035666s
2023/05/16 18:00:48.587000 [SNR] Buffer statistics for "TV/Deadliest Catch/Deadliest Catch S19E05 In Need of Rescue 2023-05-16-1757.mpg": buf=0% drop=0%
2023/05/16 18:00:48.588677 [MTS] Statistics for "TV/Deadliest Catch/Deadliest Catch S19E05 In Need of Rescue 2023-05-16-1757.mpg": skipped=0 unhandled_packets=0 discontinuity_detected=0 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=false saw_pmt=false highest_pts=0.000000
2023/05/16 18:00:48.591277 [TNR] Closed connection to TVE-Comcast_SSO for ch6101 DISCOVERY
2023/05/16 18:00:48.591304 [DVR] Error running job 1684285045-ch6101 Deadliest Catch: astits: PCR PID invalid```We're looking into it.
Update: We're releasing an update that reverts the change. It should be out shortly.
1 Like
Newest one is now working
2 Likes
I don't use TVE, but until this last update Pluto was broken here. The odd part is it didn't break SamsungTV channels.
My log entries looked something like this:
2023/05/16 20:10:24.811919 [TNR] Opened connection to M3U-Pluto for ch1020 Paramount Movie Channel
2023/05/16 20:10:24.866288 [HLS] Starting live stream for channel 1020 from 192.168.0.104 (bitrate=3063)
2023/05/16 20:10:25.770702 [HLS] ffmpeg: ch1020-dANY-ip192.168.0.104-remux: Output file #0 does not contain any stream
2023/05/16 20:10:25.837631 [HLS] Couldn't generate stream playlist for ch1020-dANY-ip192.168.0.104: Stream stopped
2023/05/16 20:10:25.837631 [HLS] Stopping transcoder session ch1020-dANY-ip192.168.0.104
2023/05/16 20:10:25.842630 [TNR] Closed connection to M3U-Pluto for ch1020 Paramount Movie Channel
And tuning anything from my Shield Pro client gave me this:
I knew something was off when I saw it said Pluto was "streaming to the HDHomerun". Tuning from my Win10 web interface would simply try to reconnect several times then quit. Nothing checked on the "Experimental" section of the server settings.
As I said the most recent DVR Pre-release in this thread fixed it. I just thought it was odd since I wasn't turning on any experimental stuff.
1 Like
What version are you on? Is there a newer release available for you to update to?
Assuming you're replying to me, 2023.05.17.0130.
The version before that broke Pluto, the above version fixed it. I just thought it was odd since I don't use any of the "experiments".
Don't know if it's a regression or the New MPEG-TS Rewriter is being used when it's not enabled.
Seeing the same thing again, this time with a Pluto channel recording.
Takes over a minute for the right click on recording file context menu to come up in Windows.
TSReader shows that the PMT says the PCR is on PID 8191 (0x1fff). That's the Null Packet PID.
Wierd, the actual Video is on PID 481 (0x01e1) and Audio is on PID 492 (0x01ec)
Stranger still is that Video PID 256 (0x0100) contains only ads.
2023/06/10 10:28:00.003203 [DVR] Starting job 1686418080-127 Star Trek: Strange New Worlds on ch=[9054]
2023/06/10 10:28:09.006841 [M3U] stream timestamps: mixible: start_at=2023-06-10T16:54:24-07:00 end_at=2023-06-10T16:56:02-07:00 live_delay=24s
2023/06/10 10:28:09.007228 [TNR] Opened connection to M3U-Pluto for ch9054 Mixible
2023/06/10 10:28:09.007830 [DVR] Recording for job 1686418080-127 from M3U-Pluto ch9054 into "TV/Star Trek Strange New Worlds/Star Trek Strange New Worlds 2023061010 2023-06-10-1028.mpg" for 33m59.996495206s
2023/06/10 10:28:09.454549 [IDX] Generating video index for job 1686418080-127
2023/06/10 11:02:24.024238 [TNR] Closed connection to M3U-Pluto for ch9054 Mixible
2023/06/10 11:02:24.108958 [SNR] Buffer statistics for "TV/Star Trek Strange New Worlds/Star Trek Strange New Worlds 2023061010 2023-06-10-1028.mpg": buf=0% drop=0%
2023/06/10 11:02:24.320428 [MTS] Statistics for "TV/Star Trek Strange New Worlds/Star Trek Strange New Worlds 2023061010 2023-06-10-1028.mpg": skipped=0 unhandled_packets=0 discontinuity_detected=18 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=true saw_pmt=true highest_pts=2080.482311
UPDATE: Looks like it was fixed since v2023.06.05.2257, not seeing it in v2023.06.08.0458. The ads are still in PIDs 256 & 257, but the PMT is now correct.
1 Like
Happened again running v2023.06.08.0458
It took over 4 minutes to bring up properties of the recorded file in Windows explorer.
PMT says PCR is on PID 8191 (0x1fff)
The Video and Audio ES stream PIDs the PMT points to, 256 (0x0100) & 257 (0x0101) are only ads.
The actual program Video and Audio are on PIDs 481 (0x01e1) and 492 (0x01ec)
Pretty sure you can duplicate what I'm seeing by recording this airing from the Pluto Mixible channel at 1:30 pm PT. Not sure if my 2 minutes pre and post padding contribute to it.
I saw it on the airing last night and it's not using the Smart ad detection.
2023/06/10 22:28:00.005168 [DVR] Starting job 1686461280-127 Star Trek: Strange New Worlds on ch=[9054]
2023/06/10 22:28:04.755147 [M3U] stream timestamps: mixible: start_at=2023-06-11T04:54:30-07:00 end_at=2023-06-11T04:56:06-07:00 live_delay=24s
2023/06/10 22:28:04.755506 [TNR] Opened connection to M3U-Pluto for ch9054 Mixible
2023/06/10 22:28:04.755873 [DVR] Recording for job 1686461280-127 from M3U-Pluto ch9054 into "TV/Star Trek Strange New Worlds/Star Trek Strange New Worlds 2023061022 2023-06-10-2228.mpg" for 33m59.994586294s
2023/06/10 22:28:05.161651 [IDX] Generating video index for job 1686461280-127
2023/06/10 23:02:24.043126 [TNR] Closed connection to M3U-Pluto for ch9054 Mixible
2023/06/10 23:02:24.209840 [SNR] Buffer statistics for "TV/Star Trek Strange New Worlds/Star Trek Strange New Worlds 2023061022 2023-06-10-2228.mpg": buf=0% drop=0%
2023/06/10 23:02:24.394465 [MTS] Statistics for "TV/Star Trek Strange New Worlds/Star Trek Strange New Worlds 2023061022 2023-06-10-2228.mpg": skipped=0 unhandled_packets=0 discontinuity_detected=18 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=true saw_pmt=true highest_pts=2070.611644
2023/06/10 23:02:24.516038 [DVR] Finished job 1686461280-127 Star Trek: Strange New Worlds
2023/06/10 23:02:24.676845 [DVR] Processing file-1576: TV/Star Trek Strange New Worlds/Star Trek Strange New Worlds 2023061022 2023-06-10-2228.mpg
Thank you for this report. This definitely shouldn't be behaving this way. I'll see what I can track down here.
1 Like
Seeing it on this one that's in the process of recording (same issue on two different servers recording it)
Thanks for the report!
Please let me know if this build fixes it.
1 Like
Thanks Eric.
Not easily reproducible.
Will let you know if it happens again.
Since I only saw the issue on this particular program (all three airings of it that I recorded) and no others on the same channel, I zipped up the debug recording log and emailed it to support with the Subject: Experimental TV Everywhere MPEG-TS Rewriter
Not fixed.
Updated to v2023.06.12.2008 and recorded the next airing that was on the Pluto Mixible channel and it's doing it still.
Can you try this build? It looks like there was a long-standing issues with detecting some Pluto channels and hopefully this will sort it out.
OK, scheduled the next test. Best way to reproduce is schedule a recording on that channel (I use two minute pre and post padding, not sure if it matters).
I had 3 test recordings from the Pluto Mixible channel exhibit the problem. Haven't tried other channels.
Don't want to jinx it, but looks like it's fixed!
Used a pass to record 10 programs on the channel for 20 minutes each last night and all looked good.
Setup another pass to record every airing on the channel today until 7pm for 10 minutes each.
All of these are using 2 minute pre padding.
Will update this post after they've all recorded. 
Recorded 10 minutes each of 20 episodes (7 different shows) since 9:30am on the Pluto Mixible channel and every one has correct PMT and PID's.
2 Likes
Some people including myself never enabled this because discovery networks had stabilized itself.
Im now continuing testing with this enabled.