> ## Documentation Index
> Fetch the complete documentation index at: https://bigbluebutton.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Recovering a deleted recording

title: "Recovering a recording missing from Moodle"
description: "Recover a BigBlueButton recording in Moodle when the recording still exists on the server but Moodle has no matching database row."

## Overview

This procedure covers the cases where the recording still exists on the BigBlueButton server, but Moodle has no matching row for it in `mdl_bigbluebuttonbn_recordings`. That can happen either because the Moodle row was deleted and the recording was later restored on the server, or because Moodle never created the row after a meeting creation or synchronization interruption.

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.

<Warning>
  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.
</Warning>

## When to use this procedure

Use this procedure only when Moodle does not have a row for the recording, but the recording still exists on the BigBlueButton server.

This page applies when all of the following are true:

* A recording was deleted from Moodle, intentionally or accidentally, using the Moodle recording delete action.
* The recording was later recovered or undeleted on the BigBlueButton server by the hosting provider.
* Moodle no longer shows the recording because the corresponding row in `mdl_bigbluebuttonbn_recordings` no longer exists.
* You have both the `recordID` and the `meetingID`.
* The recording still exists on the BigBlueButton server and can be returned by the BigBlueButton API.

### Missing row after meeting creation interruption (MDL-88775)

This page also applies to the missing-row scenario described in [MDL-88775](https://moodle.atlassian.net/browse/MDL-88775): Moodle created the BigBlueButton meeting successfully, but a communication failure or interruption during creation or synchronization meant the expected recording row was never inserted in Moodle.

In both cases, the important condition is the same: Moodle has no row for the recording, but BigBlueButton still has the recording.

## When not to use this procedure

Do not use this procedure when Moodle already has a row for the recording. Stop before inserting a new row if any of the following are true:

* The recording row already exists in `mdl_bigbluebuttonbn_recordings`.
* The recording exists in Moodle but is hidden because its status is `DISMISSED`.
* The recording disappeared due to the older dismissed-recording issue fixed by [MDL-76339](https://moodle.atlassian.net/browse/MDL-76339).
* The recording is hidden because of publication, visibility, import, group, or activity settings.
* The BigBlueButton server no longer has the recording.
* The Moodle activity itself was deleted and you are trying to recover all recordings associated with a deleted activity.

For these cases, do not insert another recording row. Instead, inspect the existing recording row, Moodle scheduled task output, the BigBlueButton API response, and the related troubleshooting pages.

### Missing Moodle row

Use this page when the recording exists on the BigBlueButton server, but Moodle has no row for it in `mdl_bigbluebuttonbn_recordings`.

The fix is to recreate the missing Moodle row and let Moodle synchronize the recording metadata.

### Existing Moodle row with hidden status

Do not use this page when the recording row exists in Moodle, but the recording is not shown because its status or metadata prevents it from appearing. This includes the historical `DISMISSED` status problem fixed by [MDL-76339](https://moodle.atlassian.net/browse/MDL-76339).

The fix is not to insert a new row. Inspect and correct the existing row, or follow the dedicated documentation for dismissed recordings.

## 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.

```sql theme={null}
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

This is the decisive check. Before inserting anything, confirm that Moodle does not already have a row for the recording ID.

```sql theme={null}
SELECT *
FROM mdl_bigbluebuttonbn_recordings
WHERE recordingid = 'PUT_RECORDING_ID_HERE';
```

If this query returns a row, stop here. Do not continue with the insert.

Inspect the existing row and check:

* `status`
* `imported`
* `headless`
* `courseid`
* `bigbluebuttonbnid`
* `groupid`
* `timecreated`
* `timemodified`

If a row already exists, the issue is not a missing-row recovery case. Inserting a duplicate row can make the situation worse.

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:

```sql theme={null}
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.

```sql theme={null}
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:

```sql theme={null}
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

If Moodle already has a row for the recording ID, this is not a missing-row recovery case.

Do not insert another row. Inspect the existing row and determine why Moodle is not displaying it.

Check:

* `status`
* `imported`
* `headless`
* `courseid`
* `bigbluebuttonbnid`
* `groupid`
* `timecreated`
* `timemodified`

Also review Moodle scheduled task output and the BigBlueButton API response.

### Recording exists but status is DISMISSED

This is a different recovery path. Do not use the deleted-recording recovery procedure for this case.

The older dismissed-recording issue fixed by [MDL-76339](https://moodle.atlassian.net/browse/MDL-76339) could hide recordings by setting them to `DISMISSED` after a temporary communication failure with the BigBlueButton server.

If the recording row exists and its status is `DISMISSED`, do not insert a duplicate row. Inspect and correct the existing row, or follow the dedicated documentation for dismissed recordings.

### Recording does not exist on the BigBlueButton server

Recreating the Moodle database row is not enough if BigBlueButton cannot return the recording metadata.

The recording must first be available on the BigBlueButton server. Confirm that the BigBlueButton API can return the recording for the `recordID` or `meetingID` before inserting a Moodle row.

### 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](/docs/integrations/moodle/troubleshooting/missing-recordings-after-upgrade) and [Deleted activity recordings](/docs/integrations/moodle/troubleshooting/deleted-activity-recordings) if the problem is actually a visibility or legacy-plugin issue

## Related pages

* [Find and play recordings](/docs/integrations/moodle/get-started/find-and-play-recordings)
* [Manage recordings](/docs/integrations/moodle/teachers/recordings)
* [Dismissed recordings in Moodle](/docs/integrations/moodle/troubleshooting/dismissed-recordings)
* [Missing recordings after upgrade](/docs/integrations/moodle/troubleshooting/missing-recordings-after-upgrade)
* [Deleted activity recordings](/docs/integrations/moodle/troubleshooting/deleted-activity-recordings)