No. It says TVE/M3U in the title.
I figured that was the case but HDHR also uses MPEG-TS.
Running version 2023.02.19.2355 now and option enabled.
First recording in progress and I have more than a dozen recordings scheduled in the next 24 hours.
I will keep an eye on it and report any issues.
If you don't hear from me again, that's a good sign. 
1 Like
Since I enabled the option last night:
Source Channel Recordings Status Comments
TVE (DirecTV) TruTV (6037 -> 246) 5 OK
TVE (DirecTV) Hallmark M&M (6091 -> 565) 2 OK
TVE (DirecTV) Hallmark (6090 -> 312) 2 OK
TVE (free) HSN (6951) 3 OK
TVE (free) HSN2 (6952) 2 OK
M3U (Pluto TV) Hot Bench (11125) 1 NOK Interrupted, corrupted time/duration
M3U (Frndly TV) INSP (7012) 2 OK
M3U (PLEX Live TV) Bounce XL (11629) 2 OK
Note: for DirecTV, I have the TVE channel # remapped to their official DirecTV channel # (just saying in case this might have an effect, which I doubt)
I will create a separate thread to provide more technical details about the corrupted recording.
Here is just a preview:
Thanks for all of the reports. The "Interrupted" recordings are likely going to be unrelated to this change (unless you see a panic in the logs).
The thing I'm most looking for is to hear if you see or hear any glitches when you watch recordings that were made with this turned on.
1 Like
Got it. I didn't think that the interruption was caused by this change. However, I've had interrupted recordings before but the duration was accurate (i.e. 29 min instead of 30 min). In this case, the duration is definitely messed up (26 hrs 5 min).
In case you want to take a look: Corrupted time/duration with latest MPEG-TS Rewriter (server v2023.02.19.2355)
I will continue watching recordings and let you know if I notice glitches.
The duration issue with interrupted recordings has been fixed:
2 Likes
What is the current recommendation on this? It's been a while since a non-beta DVR update was released, will this be "stable" in the next official update?
It's still experimental. When it's not experimental the checkbox will be removed and it will be the default.
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