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.
I had this option enabled on my other server, that my mother uses.
I forgot i had enabled it.
She was away for some time, now is back full time.
It was causing Pluto channels, ie Judge Judy, to have excessive buffering/pausing every so often. Have to close out the channel and reopen.
I disabled it, and never had the issue since.
This was a few weeks ago.
Has the rewriter been updated since?
Is it possible to make this option selectable per channel? Since it is only needed, it seems, on Discovery based channels.
Yes there have been several fixes recently. We are aiming to make the new rewriter the default for everyone soon. If you experience issues let us know.
Tests went great last night on discovery and history channels prime time lineup.
Programs had full length and i didnt notice any dropped frames.
3 Likes
We are continuing to have confidence that the new rewriter is handling all of the cases we have looked at better than the old one. Please let us know if you run into any issues with the new one that we need to look into further.
1 Like
It's been working fine so far.