I will update and enable the option as soon as I get the chance.
Does this have any effect on OTA HDHomerun?
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.
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.
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:
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.
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.
Newest one is now working
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.
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".