First identify the recording mode
| Mode | Where to investigate |
|---|---|
| Browser-local recording | The browser session, selected file, capture source and finalization. [S1] |
| Server/cloud recording through Jibri | The operator’s recorder service and storage. Use Jibri setup or Jibri failures. |
| Self-only local recording | The selected local microphone/camera tracks; this is not a recording of every remote participant. [S1] |
| Mobile app or embedded SDK recording | Its actual client capability and server recording service, not assumptions from a desktop browser. |
A missing local download and a failed Jibri job are different incidents. Establish which mode the recording control actually started before changing a server.
How the reviewed browser recorder saves a file
This review covers Jitsi Meet 11248 commit f765042. Its local recording manager calls showSaveFilePicker before capture starts and creates a writable file stream. The suggested extension is .webm; the picker destination can be changed by the user. [S1][S2]
Recorded chunks are queued for writing. On normal stop, the implementation waits for pending writes, updates the first chunk’s duration metadata, then closes the writable stream. It is therefore important to distinguish selecting a file, recording media and successfully finalizing that file. [S1]
Recommended checks for a missing download:
- Recall the save location you chose at the beginning and look for that file.
- Stop recording through the normal control and allow completion before navigating away.
- Check the file’s size, duration and playback, including both intended audio and video.
- If saving failed, retain the existing file and exact error privately. Do not repeatedly overwrite the same file while investigating.
A permission prompt, a selected destination or a visible recording icon alone does not establish a completed usable recording. [S1][S2][S3]
Is there a 1 GB or one-hour limit?
Do not generalize an older report or another client’s behavior to every recording mode. The reviewed manager streams chunks to a file; it does not contain a fixed one-hour timer or 1 GB stop guard in that recording path. [S1]
That observation is narrower than saying unlimited. Storage can fill, capture can stop, a browser can terminate, and a different release or provider can implement another policy. The public meet.jit.si meeting-duration policy is also separate from local file handling.
For a long session, run a disposable end-to-end test on the actual browser and storage destination for the duration you need. Plan sufficient disk space and operational recovery with the organizer. Do not advertise a supported maximum from a short test alone.
Why the control or capture can fail
The reviewed isSupported gate requires desktop Chromium, excludes Electron/React Native/mobile browsers, checks capture-handle support, requires showSaveFilePicker, and verifies the preferred MediaRecorder codec. Generic MediaRecorder support alone is not enough to pass Jitsi’s full gate. [S1][S3]
When recording the meeting rather than self-only tracks, the manager requests display capture and checks the selected surface where capture-handle support is used. It can report WrongSurfaceSelected, NoAudioTrackFound or NoLocalStreams for different conditions. Match the actual error; do not infer that every failure is a missing Jibri. [S1]
If the UI exposes multiple recording types, confirm the selected type. The recording/transcription interaction guide covers a separate version-specific mode issue.
If the file is empty, short or unplayable
Recommended diagnostic order:
- Verify that recording really started after the picker and capture steps.
- Confirm the intended source and audio were available. [S1]
- Compare an ordinary short recording stopped normally with the failing case. Record exact duration and error, not private meeting content.
- Confirm the stop/finalization path completed before the tab closed. The reviewed implementation serializes pending chunk writes before closing the file. [S1]
- Preserve any existing file. This source review does not establish that a partial or unsaved recording can be repaired.
For server recording, return to the operator’s Jibri output and service state instead. The browser’s local destination is not proof that a server backup exists.
Open questions and maintenance
Reviewed 24 October 2026. We inspected the actual capability, capture, write-queue and finalization code; we did not perform browser capture, disk-full, long-duration or recovery tests. No phone/device compatibility matrix or recording recovery guarantee is established. The article remains source-reviewed and untested in production. [S1]
Recheck after browser, client, capture workflow or recording-mode changes. A tested source version does not identify the build your provider currently serves.
Sources
- [S1] Pinned 11248 LocalRecordingManager.web.ts, capability, selected source, file writes and stop behavior.
- [S2] Browser save-file picker, security, user interaction and compatibility.
- [S3] MediaRecorder reference, recording state, data and stop lifecycle.