Live stream closes, recording uninterrupted

Multiple times during the NASCAR race today the live stream cut out, had to go back to the guide and re-opening the channel (it always happened during a commercial break) but the recording is mostly unaffected. The recording doesn't have an interrupted label, but does have a few seconds missing during each commercial break (no blank screen or scrambled picture, just as if 4-5 seconds were cut out completely).

2024/06/02 17:31:50.028449 [HLS] Couldn't generate stream playlist for ch288-dM3U-TVE-bdc8e2e0bd3a: Playlist has not been updated in 20.813510674s
2024/06/02 17:31:50.028522 [HLS] Stopping transcoder session ch288-dM3U-TVE-bdc8e2e0bd3a (out=6m44.719956s finished=false first_seq=1 last_seq=200)
2024/06/02 17:32:02.364595 [SNR] Buffer statistics for ch288 FS1: buf=0% drop=0%

I am using two DVR instances to re-number my channels in the guide, therefore my TVE source is on a "backend" DVR and then shared via MPEG-TS to the "main" DVR. Can anyone help me understand why the main DVR is seeing a 20sec+ timeout in the playlist update while only missing 4-5secs in the recording? Is there any way to avoid these interruptions when sharing TVE via an M3U playlist? I feel like something is a bit off if the recording is handled so well yet the live stream doesn't recover.

1 Like

Perhaps the devs can explain in more detail, but CDVR handles HDHR and TVE sources differently than custom m3u sources since they know more about the HDHR and TVE sources than "unknown" m3u sources. I've been bit by it before.

Was the recording made on the "main" server?
Did you check the logs on the "backend" server?

A recording will try to reconnect and continue, a client watching would see disconnected, press play to reconnect message.

1 Like

The recording was on the "main" server, so it should be sharing the same MPEG-TS cache as the live stream. The "backend" server doesn't show anything going on to cause the disruption from what I can tell, these are the only logs I see around the same time related to FS1. Theres nothing leading up to the dropped connection, only logs indicating the the stream was stopped by the "main" server...

2024/06/02 17:32:02.366784 [SNR] Rewriter statistics for 172.17.0.11 (172.17.0.11) for ch6197 FS1: discontinuity_detected=38 transport_errors=0 saw_pcr=true saw_pmt=true highest_pts=3752.540322
2024/06/02 17:32:02.367023 [SNR] Buffer statistics for 172.17.0.11 (172.17.0.11) for ch6197 FS1: buf=0% drop=0%
2024/06/02 17:32:02.367287 [SNR] Streaming statistics for 172.17.0.11 (172.17.0.11) for ch6197 FS1: timeouts=0 segment_timeouts=0 playlist_timeouts=0

Were you watching the recording in progress from the "main" dvr using the client, or did you tune to the "main" dvr channel using the client, or did you you tune to the "backend" dvr channel using the client?

As far as your "backend" dvr is concerned, it wasn't recording, just streaming TS directly to a client (your "main" dvr).

I think the devs would need to see diagnostic logs from both servers.

All user facing interactions are done through the "main" dvr, it is recording and streaming to clients using the "backend" dvr as the source. It seems the transcoders on the "main" dvr is closing after a 20s playlist timeout, which causes the live stream on the client to stop, yet the recording continues on the "main" dvr with 4-5s missing (always from a commercial). Ideally the transcoder could handle the 4-5s drop as well as the recording does without stopping the stream, but I'm not sure why the logs show a 20s timeout and the recording is only missing 5 seconds at most.

1 Like

Do you have in the M3U going to the 2nd dvr codec=copy ? that is what I use.

http://192.168.50.215:8089/devices/ANY/channels.m3u?format=ts&gracenote=include&codec=copy

No, I'm using the cached .ts stream without remuxing. I have my playlist stored on github and use the custom playlist option with the github url. The format on github...

#EXTM3U

#EXTINF:-1 channel-id="FX" tvg-id="133" tvg-chno="133" tvg-logo="https://tmsimg.fancybits.co/assets/s58574_ll_h15_aa.png?w=360&h=270" tvc-guide-stationid="58574" tvg-name="FXHD" group-title="HD",FX
http://10.10.10.50:8089/devices/ANY/channels/6080/stream.mpg

The only thing actually being used there is format=ts, which gives you an MPEG2-TS stream.
It's overriding codec=copy, which would give you an HLS stream.

So you are saying that format=ts is enough no need to use codec=copy ?

1 Like

Yes, probably don't even need format=ts either when using stream.mpg, since stream.mpg is already in TS format. Here's what Channels DVR passes to my VLC when using the VLC player integration to play my TVE ABC channel http://192.168.1.4:8190/devices/ANY/channels/6001/stream.mpg and it's a MPEG2 Transport Stream.

codec=copy is only used for an HLS stream, so it doesn't transcode the source audio or video to another codec.

This is how I have mine. I feed ome CDVR server from another. I agree with everyone else..

http://192.168.12.30:8089/devices/TVE-YouTubeTV/channels.m3u?format=ts

1 Like

I took out the format=ts&gracenote=include&codec=copy and it started transcoding which I do not want..... So I will leave it the way I had it.... got interrupted recordings which is no big deal as there is nothing really airing at the moment. Perhaps just leaving this would be enough ... format=ts&gracenote=include

2024/06/03 07:00:09.641006 [ENC] Starting encoder for ch8.1 in C:\DVR\Streaming\ch8.1-dANY-ip192.168.50.68-676606534\encoder-1-2851166405 at 1 (1.342067) (encoder=h264_mf, codec=h264, acodec=aac, resolution=1080, deinterlacer=blend, bitrate=9488, segment_size=0.01)
2024/06/03 07:00:11.294007 [HLS] ffmpeg: ch8.1-dANY-ip192.168.50.68-1-h264-aac-copy--9488-256-1080-6-0---false-false-0.01-0:  [h264_mf @ 0000000001f90980] stream format change
2024/06/03 07:00:13.567173 [DVR]   indexed 838 airings (118 channels) [6s fetch, 460ms index]
2024/06/03 07:00:19.907240 [DVR]   indexed 41 movies (16 channels) [6s fetch, 36ms index]
2024/06/03 07:00:19.912166 [DVR] Fetching guide data for 106 stations in X-TVE @ 2024-06-17 6:00AM
2024/06/03 07:00:23.059539 [DVR]   indexed 705 airings (106 channels) [2s fetch, 326ms index]
2024/06/03 07:00:30.170362 [DVR]   indexed 22 movies (8 channels) [7s fetch, 34ms index]
2024/06/03 07:00:30.176302 [DVR] Fetching guide data for 169 stations in X-M3U @ 2024-06-17 12:00PM
2024/06/03 07:00:39.477649 [HLS] Stopping inactive session ch8.1-dANY-ip192.168.50.68
2024/06/03 07:00:39.478240 [HLS] Stopping transcoder session ch8.1-dANY-ip192.168.50.68 (out=33.607644s finished=false first_seq=1 last_seq=17)

with format=ts&gracenote=include&codec=copy it just opened the connection no transcoding ... which is what I want.

2024/06/03 07:06:46.557280 [TNR] Opened connection to 107829D3/0 for ch8.1 KGW

From: How create custom channel using a remote Channels DVR server as a video source - #34 by eric

I am not sure that works with when you have ANY when using ANY M3U from dvr to dvr. http://192.168.50.215:8089/devices/ANY/channels.m3u internally defaults to hls ... so format=ts is required.

#EXTINF:-1 channel-id="2.1" tvg-id="2.1" tvg-chno="2.1" tvg-logo="https://tmsimg.fancybits.co/assets/s28708_h3_aa.png?w=360&h=270" tvc-guide-stationid="20292" tvg-name="KATUDT" group-title="Favorites",ABC
http://192.168.50.215:8089/devices/ANY/channels/2.1/hls/master.m3u8?

This works for me ....

Yes when using url format=ts will not transcode. No need for codec=copy which is for hls remux only. Ts is faster to tune but hls is more robust with latency.

Reply without codec=copy it transcodes hls

That’s using text to build the source, using ts and url to build the source like @slampman above format=ts doesn’t transcode

That is without codec=copy ... I will just leave it the way I know it works....unless someone has a better way to do DVR to DVR sending all Channels without transcoding.

024/06/03 09:42:13.436259 [HLS] Starting live stream for channel 8.1 from fe80::d7ab:9d86:a511:77ce%Ethernet
2024/06/03 09:42:15.434900 [HLS] Probed live stream in 1.9986412s: mpeg2video 1920x1080 tt 7061801bps
2024/06/03 09:42:17.108474 [DVR] indexed 3539 airings (368 channels) [3s fetch, 1s index]
2024/06/03 09:42:18.053465 [DVR] indexed 153 movies (48 channels) [851ms fetch, 93ms index]
2024/06/03 09:42:18.063391 [DVR] Fetching guide data for 368 stations in X-M3U @ 2024-06-05 3:30AM
2024/06/03 09:42:18.219199 [HLS] Session ch8.1-dANY-ipfe80--d7ab-9d86-a511-77ce-Ethernet started in 4.7829399s
2024/06/03 09:42:18.223553 [ENC] Starting encoder for ch8.1 in C:\ChannelsDVR\Streaming\ch8.1-dANY-ipfe80--d7ab-9d86-a511-77ce-Ethernet-1597732575\encoder-1-2226916698 at 1 (2.454633) (encoder=h264_mf, codec=h264, acodec=aac, resolution=1080, deinterlacer=blend, bitrate=9488, segment_size=0.01)
2024/06/03 09:42:18.764637 [HLS] ffmpeg: ch8.1-dANY-ipfe80--d7ab-9d86-a511-77ce-Ethernet-1-h264-aac---9488-256-1080-6-0---false-false-0.01-0: [h264_mf @ 0000000001247ec0] stream format change

This is with =ts and without codec=copy

2024/06/03 11:14:56.166794 [TNR] Opened connection to xxxxxxxxx/0 for ch19.1 KCPT-1
2024/06/03 11:15:06.602752 [SNR] Statistics for ch19.1 KCPT-1: ss=100% snq=82%,79%-88% seq=100% bps=6457875,1075360-7899008 pps=552,92-676
2024/06/03 11:15:06.602971 [SNR] Buffer statistics for xxx.cxx.xxx.57 ([email protected] (xxx.cxx.xxx.57)) for ch19.1 KCPT-1: buf=0% drop=0%
2024/06/03 11:15:06.615080 [TNR] Closed connection to xxxxx/0 for ch19.1 KCPT-1
2024/06/03 11:18:44.117158 [TNR] Opened connection to xxxxxxxxx/0 for ch19.1 KCPT-1
2024/06/03 11:19:20.511817 [SNR] Statistics for ch19.1 KCPT-1: ss=100% snq=88%,73%-100% seq=100% bps=7462848,1696512-7908032 pps=639,145-677
2024/06/03 11:19:20.512010 [SNR] Buffer statistics for xxx.cxx.xxx.57 ([email protected] (100.120.137.57)) for ch19.1 KCPT-1: buf=0% drop=0%
2024/06/03 11:19:20.523070 [TNR] Closed connection to xxxxxxxxx/0 for ch19.1 KCPT-1

No transcode

I might be confusing myself going to get another cup of coffee doing too many things at once ... I will try it again your way.