Description
We run the new bridge-native transcription/recording flow (jicofo transcription.url-template → JVB colibri2 connect → jitsi-multitrack-recorder). Because the transcriber is a bridge-side connect and not a chat room member, jicofo does not count it as a media consumer: when a meeting briefly drops to one participant (e.g. someone reconnects because of a bad network or a wifi→ethernet switch), the single-participant timeout (jicofo.conference.single-participant-timeout, default 20s) expires the lone participant's media session and the bridge conference — tearing down the transcriber websocket and finalizing the recording mid-meeting, even though the recorder was actively consuming the audio.
When the second participant rejoins moments later, a new bridge conference is created for the same meetingId, and the multitrack recorder deliberately starts a new session in a <meetingId>-1 directory (jitsi/jitsi-multitrack-recorder#27). The result is a fragmented recording whose tail is easy to lose in downstream processing.
Steps to reproduce
- Configure async transcription with the multitrack recorder (
jicofo.transcription.url-template = "ws://recorder:8989/record/{{MEETING_ID}}"), transcription enabled for the room.
- Two participants join; recording runs.
- Participant B leaves for more than 20 seconds, then rejoins (participant A stays in the room the whole time).
Expected
While transcription/recording is active there IS a media consumer (the connect), so the conference media should keep flowing and the recording should span the whole meeting.
Actual
Exactly 20.000s after B leaves, SinglePersonTimeout expires A's media session; the colibri conference and the transcriber websocket are torn down and the recording is finalized. B's rejoin creates a new bridge conference and a second recording directory.
Timeline from our logs (jicofo 1.0-1183-1 / stable-11031, jvb 2.3-295-g8d5c0037b, jitsi-multitrack-recorder current):
10:15:20.569 jicofo guest leaves → rescheduleSingleParticipantTimeout: Scheduled single person timeout.
10:15:40.571 jicofo SinglePersonTimeout fires (exactly 20.000s) → lone participant's media session expired
10:15:40.576 jvb Received request to expire conference … recorder websocket closed (1001)
10:15:40.578 JMR RecordingSession.stop → finalize ← recording #1 ends mid-meeting
10:15:41.55x jicofo guest re-enters MUC → conference re-created (same meetingId)
10:15:41.569 JMR New recording session → /recordings/<meetingId>-1 ← fragment
A rejoin within the 20s window cancels the timer and nothing breaks — the problem is only the (very common) reconnect that takes longer than 20s.
Suggestion
Treat an active transcriber/recorder connect as a media consumer for conference lifecycle purposes — e.g. suppress (or make configurable) the single-participant timeout while transcription is active. #1066 established the inverse precedent (jigasi transcribers/jibri are excluded from the participant count for visitor redirection); here the bridge-side connect needs to be counted so the recording survives.
Workaround
jicofo.conference.single-participant-timeout = 10 minutes works for us, at the cost of keeping any lone participant's media session alive that long in every conference, recorded or not.
Description
We run the new bridge-native transcription/recording flow (jicofo
transcription.url-template→ JVB colibri2connect→ jitsi-multitrack-recorder). Because the transcriber is a bridge-side connect and not a chat room member, jicofo does not count it as a media consumer: when a meeting briefly drops to one participant (e.g. someone reconnects because of a bad network or a wifi→ethernet switch), the single-participant timeout (jicofo.conference.single-participant-timeout, default 20s) expires the lone participant's media session and the bridge conference — tearing down the transcriber websocket and finalizing the recording mid-meeting, even though the recorder was actively consuming the audio.When the second participant rejoins moments later, a new bridge conference is created for the same
meetingId, and the multitrack recorder deliberately starts a new session in a<meetingId>-1directory (jitsi/jitsi-multitrack-recorder#27). The result is a fragmented recording whose tail is easy to lose in downstream processing.Steps to reproduce
jicofo.transcription.url-template = "ws://recorder:8989/record/{{MEETING_ID}}"), transcription enabled for the room.Expected
While transcription/recording is active there IS a media consumer (the connect), so the conference media should keep flowing and the recording should span the whole meeting.
Actual
Exactly 20.000s after B leaves,
SinglePersonTimeoutexpires A's media session; the colibri conference and the transcriber websocket are torn down and the recording is finalized. B's rejoin creates a new bridge conference and a second recording directory.Timeline from our logs (jicofo 1.0-1183-1 / stable-11031, jvb 2.3-295-g8d5c0037b, jitsi-multitrack-recorder current):
A rejoin within the 20s window cancels the timer and nothing breaks — the problem is only the (very common) reconnect that takes longer than 20s.
Suggestion
Treat an active transcriber/recorder connect as a media consumer for conference lifecycle purposes — e.g. suppress (or make configurable) the single-participant timeout while transcription is active. #1066 established the inverse precedent (jigasi transcribers/jibri are excluded from the participant count for visitor redirection); here the bridge-side connect needs to be counted so the recording survives.
Workaround
jicofo.conference.single-participant-timeout = 10 minutesworks for us, at the cost of keeping any lone participant's media session alive that long in every conference, recorded or not.