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

# Dismissed recordings in Moodle

> Understand why recordings can be marked as DISMISSED, what MDL-76339 changed, and how to recover using scheduled tasks or CLI.

## Overview

In BigBlueButton for Moodle, a recording row can be marked with status `DISMISSED` when Moodle cannot fetch that recording metadata from the BigBlueButton server during synchronization.

In many sites, this happens as expected when the recording no longer exists on the BigBlueButton server, such as trial environments with short recording retention windows.

It can also appear as an edge case when the recording still exists, but Moodle temporarily cannot retrieve it.

## Historical issue: MDL-76339

[MDL-76339](https://moodle.atlassian.net/browse/MDL-76339) documented a historical issue where recordings could become `DISMISSED` when they were temporarily unreachable from the BigBlueButton API.

The key improvement was adding a recovery path that rechecks dismissed recordings and restores them to a visible status when metadata becomes available again.

## Possible cases that can lead to DISMISSED

### Expected case: recording no longer exists on BBB

* recording retention expired on the BigBlueButton hosting side
* recording was permanently deleted on the BigBlueButton server
* recording was removed by hosting lifecycle policy

In this case, `DISMISSED` is expected behavior.

### Temporary fetch failures

* transient network issues between Moodle and BigBlueButton
* temporary BigBlueButton API unavailability
* intermittent proxy or infrastructure failures

If metadata cannot be fetched at that moment, the recording can be classified as dismissed.

### Partial or inconsistent API results (edge case)

A less common case is when the API call succeeds, but the expected recording is missing from the response at that moment. This can happen during backend propagation delays, brief storage inconsistencies, or other transient server-side conditions.

### Mixed state around restores and deletions

If a recording is restored, moved, or reprocessed on the BigBlueButton side while Moodle is synchronizing, Moodle may observe a temporary missing state and set the local row to `DISMISSED` before the next successful refresh.

## Automatic recovery via scheduled task

Moodle can recover dismissed recordings automatically through the scheduled task:

* **Check for recordings that haven't been found yet**

This task rechecks dismissed recordings against the BigBlueButton server and updates them when metadata is found.

## Important limitation of task-based recovery

Automatic recovery is not immediate in every environment.

* it depends on your cron schedule and task timing
* it only processes dismissed rows within the configured 30-day window
* rows older than that window are not rechecked automatically by the dismissed-recordings task
* if metadata is still unavailable when the task runs, recovery is deferred

Because of these limits, a dismissed recording can remain hidden for some time even when it later becomes available on BigBlueButton.

If a dismissed row is older than 30 days, use the CLI script for a manual recheck.

## Manual recovery with CLI script

When faster intervention is required, an administrator can run the CLI script directly:

```bash theme={null}
php mod/bigbluebuttonbn/cli/update_dismissed_recordings.php --run=1
```

Useful scoped examples:

```bash theme={null}
php mod/bigbluebuttonbn/cli/update_dismissed_recordings.php --courseid=123 --run=1
php mod/bigbluebuttonbn/cli/update_dismissed_recordings.php --bigbluebuttoncmid=456 --run=1
```

Dry-run mode (report only):

```bash theme={null}
php mod/bigbluebuttonbn/cli/update_dismissed_recordings.php --courseid=123 --run=0
```

## Suggested triage flow

1. Confirm whether the recording still exists on the BigBlueButton server.
2. Check the Moodle row in `mdl_bigbluebuttonbn_recordings` and verify `status`.
3. Run the dismissed-recording task or wait for cron.
4. If recovery is urgent, run the CLI script with `--run=1`.
5. Recheck the recording list in the activity.

## Related pages

* [Recovering a deleted recording](/integrations/moodle/troubleshooting/recovering-a-deleted-recording)
* [Missing recordings after upgrade](/integrations/moodle/troubleshooting/missing-recordings-after-upgrade)
* [Deleted activity recordings](/integrations/moodle/troubleshooting/deleted-activity-recordings)