Live-class recording

A live class is recorded automatically. The recorder starts on the first published track, and the finished file becomes a recording that enrolled founders can play.

Automatic live-class recording. A mentor starts a class and the LMS service sets it to in progress. When a participant publishes a track, the LiveKit server sends a signed track_published webhook to the LMS service, which starts a room-composite egress. When the mentor ends the class the LMS service stops the egress. The egress writes the MP4 to the bucket, and the server sends an egress_ended webhook. The LMS service then creates the recording and marks the class ready.

States

The live class has two separate status fields.

Live class status. A class starts as scheduled, moves to in progress when started, then completed when ended. It can be cancelled from scheduled. Separately the recording status goes from none to recording when the first track is published, to processing when the class ends, and to ready when the egress completes.

The diagrams show the intended path. The service does not guard the order: start, end and cancel set the status whatever the current state is. A class that nobody ever publishes into stays at recording status NONE. That is correct: there is nothing to record.

Why it starts on the first track

An earlier version started the egress when the class started. In an empty room the composite layout renders nothing and never signals that it has started, so the egress timed out with code 412 ("Start signal not received") and no file was written. Starting on track_published fixed it. See ADR 6.

Playback

The recording is listed for enrolled learners at GET /api/v1/lms/recordings/course/{courseId} and played through the same stream-token mechanism as lesson video. See Video upload and Range streaming.

Sources: services/lms-service/src/main/java/com/rtih/startupos/lms/{service/LiveClassService,resource/EgressWebhookResource}.java, .agents/tasks/lms-egress-412/fix-report.md.