Not all recordings are visible in Moodle

[LGPoly]

Hi, We're having an issue in few meetings where some recordings are properly fetched by the plugin, but for some reason, others don't appear to be listed in Moodle. Here's an example of what we can see in Moodle:

Here's the corresponding recordings in the admin interface of Zoom, for the meeting id:

The host is the same, the meeting was set to record automatically in the cloud, and the Participants are allowed to join anytime - which is kinda weird, we sent a notice to our users regarding that:

We just updated to 5.1.0 this morning, hoping that would fix the issue, but even after running the task mod_zoom\task\get_meeting_recordings it seems the Recording id is not looked for.

We tried to delete a recording that was visible on both sides, and it was properly delisted in Moodle after running the \mod_zoom\task\delete_meeting_recordings.

Any help will be welcomed :)

Thanks, Lucas

[LGPoly]

I managed to call Zoom's API using Postman @ {{baseUrl}}/users/:userId/recordings?include_fields=a2f19f96-9294-4f51-8134-6f0eea108eb2&ttl=1&meeting_id=[MeetingID]&from=2023-08-01&to=2023-09-05 and all 5 records showed up.

But, as you may already know, the authentication is different when calling directly Zoom's API, so I created an App Credentials in Zoom and used the Grant Type Authorization Code in Postman.

Related API's doc: https://developers.zoom.us/docs/meeting-sdk/webhooks/#operation/recordingsList

Forgot to mention we're using Moodle Version 4.1.4 with security fixes applied. mod_zoom is fully vanilla, with an Server-to-Server OAuth authentication.

[LGPoly]

My bad, unintentionally closed it..

[LGPoly]

Update: Calling {{baseUrl}}/meetings/:meetingId/recordings?include_fields=a2f19f96-9294-4f51-8134-6f0eea108eb2&ttl=1 : gets the last recording created only. I figure it's because of the meetingID passed, which isn't the meeting uuid, but I can't get my hands on it. I've tried calling the meeting uuid that I get by calling {{baseUrl}}/meetings/:meetingId as it seems that's what the plugins does in \mod\zoom\classes\webservice.php but I get an error "3301 - This recording does not exist." so I guess I'm doing something incorrect..

[LGPoly]

Ok, so I found kind of a workaround, which is to delete all the recordings of students starting the meeting by themselves, till the one really interesting, of the virtual lesson, is the last one created. Then it looks like the plugin has no other choice then to fetch this one and show it in Moodle. I still have an example where there are 6+ recordings in Zoom, done previously to the interesting one, but only the interesting 1 is fetched by the plugin. Could it be the fact that the cron mod_zoom\task\get_meeting_recordings runs every 1 hour on our Moodle (every 3 hours by default), and only gets the last created recording? So when, in the same hour span, and in between 2 cron executions, several recordings are created, the plugin only gets the last one created?

[jrchamp]

Hi @LGPoly, it looks like you are correct!

The Get meeting recordings API method, GET /meetings/{meetingId}/recordings, says this:

To get a meeting's cloud recordings, provide the meeting ID or UUID. If providing the meeting ID instead of UUID, the response will be for the latest meeting instance.

So if we can't rely on that API method to get us all of the recordings, then the two options that I see are:

• Using List past meeting instances and then looping through the meeting instance UUIDs
• Using List all recordings and limiting the search to the meeting owner, the last day or so and the meeting numeric ID (meeting_id).

Both options are categorized as "Medium", so I'm tempted to rework the task so that it uses the "List all recordings" API method.

To minimize API calls, we could:

1. Use zoom_get_meeting_recordings_grouped() so that we can preload all of the local recording entries.
2. Create, in memory, a (Zoom host + Zoom meeting_id) to Zoom activity id mapping to make it easy to know if the recording is for a Moodle Zoom activity.
3. Process all of the recordings for a user that match the Zoom meeting_id and host in the local Moodle database.
4. Keep track of which users have already been processed and skip processing them later in the loop.