Recorded meeting start_time and duration not representative of contained recordings

API and Webhooks
1

Description
When using the listRecordedMeetings (for a user) API endpoint, I notice that the meeting.start_time is different from the meetings.recording_files.recording_start of the recording. Usually it’s only a couple seconds which is understandable if they are modeling closely correlated events. In one case, for a meeting that was being auto-recorded, the meetings[0].start_time was about 5.5 hours earlier than the recording_files.start_time (aka recording_start) Yet, surprisingly the duration of the meeting was 207 minutes - exactly the same number of minutes as the recording.

What do the meeting.start_time and duration signify, and how can they be non overlapping with the recordings they envelop?

Error
The issue is that the meeting structure start_time and duration don’t describe the time period when the meeting took place.

Which App Type (OAuth / Chatbot / JWT / Webhook)?
Using the Cloud Recording API List All Recordings endpoint, below

Which Endpoint/s?
GET /users/{userId}/recordings

How To Reproduce (If applicable)
N/A

Screenshots (If applicable)
N/A

Additional context
Here is a redacted version of the JSON response from my call:

{
“from”: “2020-09-10”,
“to”: “2020-10-12”,
“page_count”: 1,
“page_size”: 100,
“total_records”: 1,
“next_page_token”: “”,
“meetings”: [
{
“uuid”: “------------------------”,
“id”: --------------------,
“account_id”: “-------------------------------”,
“host_id”: “--------------------------------”,
“topic”: “ZOOM Link for Morning General Sessions (8:00 AM - 11:45 AM MST)”,
“type”: 2,
"start_time": “2020-10-12T10:46:30Z”,
“timezone”: “America/Phoenix”,
"duration": 207,
“total_size”: 1834638690,
“recording_count”: 3,
“share_url”: “https://--------.zoom.us/rec/share/-----------------”,
“recording_files”: [
{
“id”: “-------------------------------”,
“meeting_id”: “-----------------------------------”,
"recording_start": “2020-10-12T15:18:43Z”,
"recording_end": “2020-10-12T18:46:03Z”,
“file_type”: “MP4”,
“file_size”: 1834621489,
“play_url”: “https://-----------.zoom.us/rec/play/---------------------------”,
“download_url”: “https://--------------.zoom.us/rec/download/---------------------------”,
“status”: “completed”,
“recording_type”: “shared_screen_with_speaker_view”
},
{
“meeting_id”: “------------------------”,
“recording_start”: “2020-10-12T15:18:43Z”,
“recording_end”: “2020-10-12T18:46:03Z”,
“file_type”: “TIMELINE”,
“download_url”: “https://--------.zoom.us/rec/download/--------------------------”
},
{
“id”: “-----------------------------”,
“meeting_id”: “--------------------------------------”,
“recording_start”: “2020-10-12T15:18:43Z”,
“recording_end”: “2020-10-12T18:46:03Z”,
“file_type”: “CHAT”,
“file_size”: 17201,
“play_url”: “https://------------.zoom.us/rec/play/----------------”,
“download_url”: “https://--------.zoom.us/rec/download/----------------”,
“status”: “completed”,
“recording_type”: “chat_file”
}
]
}
]
}

2

Hey @rnahf,

Thanks for pointing this out—I’m looking into why this might be the case. (ZOOM-206594).

I’ll be in touch!
-Will

3

Thanks, Will.

For context, our system is trying to collect and filter recorded meetings for a scheduled meeting that has auto-record turned on. This is for a virtual conference with different zoom meetings at different times of the day, and occasionally, attendees click on the wrong link and show up at the wrong time. For the meetings where auto-record is enabled, extra recorded meetings under the original meeting ID are created, and we are trying to filter those out automatically based on overlap with the scheduled meeting time to make it easier to give attendees play_urls when the recording become available.

4

Hey @rnahf,

Thanks for providing these additional details. I’ve just circled back with my team to get an update on this, as I can definitely appreciate the importance of getting this right in your case. I should be in touch shortly.

Thanks,
Will

5

Hey @rnahf,

After taking a closer look at this, my team helped to clarify that the “start_time”: “2020-10-12T10:46:30Z” is the meeting start time, while the “recording_start”: “2020-10-12T15:18:43Z” is the recording start time.

In other words, these are two different times—one reflecting when the meeting itself started and the other reflecting when recording started (and the recording can only be started after the meeting is started, so it would make sense that these would be different).

Let me know if this helps to clarify,
Will

6

Hi Will,

Thanks, that’s what I figured, but I still am confused as to why the meeting.duration field puts the meeting ending before the mp4 recording belonging to it starts. Unless the meeting.duration doesn’t describe duration of the meeting, just the duration of enclosed recordings?

From the JSON schema from the API document, my auto-generated code has this comment:

 /**
 * Meeting duration.
 * 
 */
@SerializedName("duration")
@Expose
private Integer duration;

I guess I’m strongly suspecting the latter - that meeting.duration describes the total length of recordings of a meeting, and the API documentation is wrong / unintentionally vague for this circumstance.

-Rob

7

Hi Will,

I’m going to mark this one as resolved on my end. Assuming meeting.duration is more descriptive of the contained recordings than the actual meeting duration, it would be great if that could be clarified on your end in the documentation.

For my use case, I ended up looping through the recording files within a meeting instance and used the earliest recording start time and latest recording end time of the mp4s in completed status. That gives me a direct way to figure out the recording overlap with the scheduled meeting time.

Thanks for your attention on this one.

8

Hey @rnahf,

Thank you for the context, as well as for providing that workaround—I’m sure others will find that to be a helpful suggestion. Going forward, I will work with our team to improve the clarity of the documentation around this.

Best,
Will