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

AlanM

Member
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:
upload_2020-2-27_10-48-5.png

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

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

Max

Administrator
Staff member
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

Member
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

Administrator
Staff member
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:
Code:
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}
 
Top