Stream recording template variables for startTime and endTime return 2090 as the year

[AlanM]

We've noticed that our stream recordings are getting saved with a date from the year 2090 (and possibly subtracting 1 day). The time of day is correct.

WCS.version
5.2.471-bf1bc0669ecac4c62f68801ec3301a1ce241a1d3

We've confirmed this is occurring on the example stream recording page (/shared/examples/demo/streaming/stream_recording)

Our template config:
stream_record_policy=template
stream_record_policy_template={startTime}_{endTime}_{streamName}_{mediaSessionId}_{audioCodec}_{videoCodec}
record_rotation=300
record_rotation_index_enabled=false

Monitoring /records directory with watch command:

3791809790405_3791810090508_100287_31388870-596c-11ea-b29c-4535cbc19125_opus_H264.mp4

3791809790405 Start Time converts to:
GMT: Sunday, February 26, 2090 4:29:50.405 PM
Your time zone: Sunday, February 26, 2090 10:29:50.405 AM GMT-06:00

3791809790405 should be
1582820990405

 

[Max]

Good day.
We reproduced the issue and raised internal ticket (WCS-2565) to fix it. We'll let you know results here.

 

[Max]

Good day.
We inbvestigated the issue. Since we implemented exact recording duration calculation by your request, the server time is not used anymore, all the time information we get from stream timestamps received. The stream timestamps, in their turn, are set by browser (or another stream source: ffmpeg, OBS and so on). Therefore, stream timestamps can differ from server time. For example, stream timestamps are always start from zero for RTMP streams.
So if you need to use server time in record names and exact recording duration at the same time, we suppose to implement {startServerTime} and {endServerTime} template items. But those items should not be used to calculate recording duration. Please specify whether this solution is suitable for you. If yes, we will do this as part of the ticket WCS-2565.

 

[AlanM]

Good day.
We inbvestigated the issue. Since we implemented exact recording duration calculation by your request, the server time is not used anymore, all the time information we get from stream timestamps received. The stream timestamps, in their turn, are set by browser (or another stream source: ffmpeg, OBS and so on). Therefore, stream timestamps can differ from server time. For example, stream timestamps are always start from zero for RTMP streams.
So if you need to use server time in record names and exact recording duration at the same time, we suppose to implement {startServerTime} and {endServerTime} template items. But those items should not be used to calculate recording duration. Please specify whether this solution is suitable for you. If yes, we will do this as part of the ticket WCS-2565.

Yes, please implement {startServerTime} and {endServerTime} template items

Thank you!

 

[Max]

Ok, we'll let you know when feature will be released

 

[Max]

Good day.
We implemented server time template items in build 5.2.635, both in milliseconds:
{startTimeMillis} - recording start time based on server clock
{endTimeMillis} - recording end time based on server clock
For example:

stream_record_policy_template={streamName}-{startTimeMillis}-{endTimeMillis}-{duration}

Note that in general stream time stamps are different from server clock time stamps, so {endTimeMillis} - {startTimeMillis} != {duration}