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.
When @tmm1 mentioned that you would soon be making it the default I started using it. I have noticed no issues to report. It’s working great for me on my admittedly generic Synology/YoutubeTv setup. Hopefully once this becomes a default maybe it will make things easier with the CC for Pluto dream.
1 Like
After enabling this, I'm no longer getting the MTS stats in the log for recordings, like this
Can they be added back.
highest_pts, saw_pcr, skipped and unhandled_packets are useful.
1 Like
Not really as such. The new rewriter doesn't operate the same way as the old one, so skipped= and unhandled_packets= aren't a thing that is meaningful in the new system.
I can look at adding back highest_pts=, but the meaning in the new system is somewhat different from what it was before...
1 Like
Thanks. Mainly useful for interrupted recordings so I can quickly locate the spot in my video editor where Channels DVR stitched the stream back together.
saw_pcr=false meant something was changing the PMT to say the PCR was in a PID when there was actually no PCR in the stream EXPERIMENTAL: New MPEG-TS Rewriter for HLS (TVE) - #84 by chDVRuser
I enabled this 2 weeks ago on all four DVR servers and haven't seen any issues with recordings or Live.
Using TVE and M3U sources.
2 Likes
Will post if any issues with these 21 one hour recordings this week (Shark Week on Discovery).
Day one 4 hrs of back-back recordings, all good
Day two 3 hrs of back-back recordings, all good
Day three 3 hrs of back-back recordings, all good
Day four 3 hrs of back-back recordings, all good
Day five 3 hrs of back-back recordings, all good
And after recording, updated to
and
just to make sure I'm testing w/latest version
Day six 3 hrs of back-back recordings, all good
Day seven 2 hrs of back-back recordings, all good
All 21 hours without any issues.
Pausing the pass until next year.
Thanks @eric for the work on the new rewriter!
1 Like