Skip to main content

​
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 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: 
php mod/bigbluebuttonbn/cli/update_dismissed_recordings.php --run=1
Useful scoped examples: 
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): 
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.