Skip to main content

​
Overview

This procedure applies when the recording still exists on the BigBlueButton server, but Moodle no longer shows it because the Moodle recording record was removed. Moodle displays recordings from the records stored in its database. If that row is deleted, Moodle no longer knows the recording exists, even if the recording has been recovered or undeleted on the BigBlueButton server. Recreating the missing database row allows Moodle to rediscover the recording during the next recording synchronization run.
This is an advanced recovery procedure. Make a database backup first, use administrator-level access, and only apply these steps when normal recording recovery is not enough.

​
Prerequisites

Before you begin, obtain both of the following values:
  • recordID
  • meetingID
Example values:
  • recordID: 4e3527b0bd6b213b47a6a923fb5a67909d59a5e4-1780494335460
  • meetingID: 16ae3bfa7bdffe133fd93ee4afc40727db0a4045-202-198[0]
You can usually get these values from:
  • BigBlueButton API responses
  • recording metadata
  • hosting provider support staff

​
Step 1: Identify the Moodle Activity

Use the meeting ID to find the Moodle activity that owns the recording. 
SELECT
    b.id AS bigbluebuttonbnid,
    b.course AS courseid,
    c.fullname AS coursename,
    b.name AS activityname
FROM mdl_bigbluebuttonbn b
JOIN mdl_course c ON c.id = b.course
WHERE b.meetingid = 'PUT_MEETING_ID_HERE';
Expected output:
  • one row for the matching BigBlueButton activity
  • the course ID and course name that own the activity
  • the activity name that Moodle will use when it redisplays the recording
If no rows are returned, the meeting ID does not match a current Moodle activity.

​
Step 2: Verify the Recording Does Not Already Exist

Check whether Moodle already has a row for the recording ID. 
SELECT *
FROM mdl_bigbluebuttonbn_recordings
WHERE recordingid = 'PUT_RECORDING_ID_HERE';
If a row already exists, stop here and investigate why the recording is still missing from the interface. Do not create duplicate rows. Continue only if no rows are returned.

​
Step 3: Recreate the Missing Recording Entry

The recording ID usually ends with a Unix timestamp in milliseconds. Extract that timestamp from the recording ID and convert it to seconds for Moodle’s timecreated value. Do not use the millisecond value directly. For example, if the recording ID is 4e3527b0bd6b213b47a6a923fb5a67909d59a5e4-1780494335460, the trailing value 1780494335460 is the millisecond timestamp. The corresponding timecreated value is 1780494335. You can also derive the value in SQL with: 
SELECT FLOOR(CAST(SUBSTRING_INDEX('4e3527b0bd6b213b47a6a923fb5a67909d59a5e4-1780494335460', '-', -1) AS UNSIGNED) / 1000);
Use the matching course ID and BigBlueButton activity ID from Step 1, then insert the missing row. 
INSERT INTO mdl_bigbluebuttonbn_recordings
(
    courseid,
    bigbluebuttonbnid,
    groupid,
    recordingid,
    headless,
    imported,
    status,
    importeddata,
    timecreated,
    timemodified,
    usermodified
)
VALUES
(
    PUT_COURSE_ID_HERE,
    PUT_BIGBLUEBUTTONBN_ID_HERE,
    0,
    'PUT_RECORDING_ID_HERE',
    0,
    0,
    0,
    NULL,
    PUT_TIMECREATED_HERE,
    UNIX_TIMESTAMP(),
    (SELECT id FROM mdl_user WHERE username = 'admin' LIMIT 1)
);
Replace mdl_ with your site’s database prefix if it is different.

​
Step 4: Trigger Recording Synchronization

After you recreate the database row, Moodle must run its recording synchronization task.

​
Run from Moodle

  1. Go to Site administration → Server → Scheduled tasks.
  2. Locate Check for pending recordings.
  3. Click Run now.

​
Or wait for Moodle cron

If you prefer, let Moodle process the recording during the next scheduled cron run.

​
Step 5: Verify Recovery

When synchronization runs, Moodle contacts BigBlueButton, fetches the recording metadata, and makes the recording visible in the activity. Use this query to confirm that Moodle now has the recording row: 
SELECT recordingid, status, timecreated, timemodified
FROM mdl_bigbluebuttonbn_recordings
WHERE recordingid = 'PUT_RECORDING_ID_HERE';
If the row exists and synchronization completed successfully, the recording should appear in the activity recordings list.

​
Troubleshooting

​
Activity cannot be located using the meeting ID

Likely causes:
  • the meeting ID belongs to a deleted or migrated activity
  • the recording came from a different Moodle site or database prefix
  • the meeting ID was copied incorrectly
Next steps:
  • verify the meeting ID with the hosting provider or API response
  • search for the activity in the Moodle database using other known fields, such as the room name or course
  • confirm that you are working in the correct Moodle site

​
Recording already exists in Moodle

Likely causes:
  • the record was already recreated by another administrator
  • the recording was never fully removed from Moodle
  • the recording row exists but the activity is filtering it out
Next steps:
  • do not insert another row
  • inspect the existing row for incorrect values
  • review the activity’s recording visibility and publication settings

​
Recording still does not appear after synchronization

Likely causes:
  • Moodle cron has not run yet
  • the scheduled task failed
  • the recording ID does not match the metadata returned by BigBlueButton
  • the recording is still not available from the BigBlueButton server
Next steps:
  • rerun Check for pending recordings and review the task output
  • confirm that BigBlueButton can return metadata for the recording ID
  • check the server logs and Moodle scheduled task history
  • compare this recovery flow with Missing recordings after upgrade and Deleted activity recordings if the problem is actually a visibility or legacy-plugin issue