Determining Live broadcast time of day at first frame of recording

Channels DVR Server
#1

Trying to figure out what the Live broadcast time of day is at the beginning of a recording from a Live custom M3U channel.

From the DVR log

2023/02/03 11:59:05.793994 [M3U] stream timestamps: SCLiveYT: start_at=2023-02-03T11:58:05-08:00 end_at=2023-02-03T11:58:30-08:00 live_delay=30.731952293s
2023/02/03 11:59:05.794478 [DVR] Recording for job 1675454340-660

Which one of these is the Live broadcast time of day at the first frame of the recording?
a 2023/02/03 11:59:05.794478 minus live_delay of 30.731952293s
b 2023-02-03T11:58:05-08:00
c 2023-02-03T11:58:05-08:00 minus live_delay of 30.731952293s
d something in the debug recording log we can look for

NOTE: I'm not looking for picosecond accuracy, more like +/- a couple seconds

#2

These timestamps are just informational based on the data in the m3u8. After having them logged for a while, we've come to the conclusion that there's no consistent relationship between those values and any real concept of when a broadcast actually was happening.

#3

Thanks eric.

Can you tell me if this log entry reflects the time the recording file is created

And about how much of the incoming HLS stream was buffered before you start writing to the recording file. Can I can search the debug recording log for that answer?

#4

Yes, that log message is indicating the recording is starting.

Following the HLS spec and to provide the best balance of realtime results and allowance for buffering, we start recording and playback of TVE streams at 3 segments back from the end. Most HLS streams on the internet have 10 second segments, so in that case, we are starting the recording and playback with 30 seconds of content.

I'm not exactly sure what you mean by "buffered" in this situation.

at=2023-01-20T12:49:44.228606-08:00 tag=... action=fetchMediaPlaylist url="https://..." status_code=200 status="200 OK" content_length=-1 playlist_count=17 target_duration=8s first_sequence=0 last_sequence=16 time=981.120125ms

For a given recording, you can see the first time we fetched the playlist and see the sequence number of the first and last segment. As referenced above, we start playback 3 segments back from the end, in this case, the segment with sequence number 14.

#5

Thank you!

File creation time from my Synology ext4 filesystem is so far off as to be unreliable.

# stat 'filespec'
 Birth: -

# debugfs -R 'stat <446922944>' /dev/mapper/cachedev_0
 ctime: 0x63dd681a:ae7e487c -- Fri Feb  3 12:01:30 2023
 atime: 0x63dd681a:c93251b0 -- Fri Feb  3 12:01:30 2023
 mtime: 0x63dd681a:ae7e487c -- Fri Feb  3 12:01:30 2023
crtime: 0x63dd6789:2f410817 -- Mon May 26 07:23:53 2431
#6

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.