Room-composite egress completes ("Source closed") before the room is deleted

Egress / Ingress
1

We started a room-composite, audio-only egress recording for a room. While the room was still active (participants still connected, not yet deleted), the egress finished on its own with status: EGRESS_COMPLETE and details: "End reason: Source closed" — so the recording stopped early and only captured part of the session.

Trying to understand why an egress’s source would close / why the egress completes while the room is still live.

Identifiers (LiveKit Cloud):

  • Egress ID: EG_uQZWiVdrzcrv
  • Room ID: RM_AEHtKQVHsoyK
  • Project ID - p_3tqm7ro6kbs

The egress_ended webhook we received:

{
  "event": "egress_ended",
  "egressInfo": {
    "egressId": "EG_uQZWiVdrzcrv",
    "roomId": "RM_AEHtKQVHsoyK",
    "sourceType": "EGRESS_SOURCE_TYPE_SDK",
    "status": "EGRESS_COMPLETE",
    "roomComposite": {
      "audioOnly": true,
      "audioMixing": "DUAL_CHANNEL_AGENT"
    }
  }
}

The EgressInfo from the API additionally shows:

status:  EGRESS_COMPLETE
details: "End reason: Source closed"

Question: for a room_composite + audioOnly egress, what causes “End reason: Source closed”, and why would the egress complete while the room is still active rather than continuing until the room ends? Is there a way to keep the recording going for the full lifetime of the room?

Can someone from the LiveKit team look up egress EG_uQZWiVdrzcrv / room RM_AEHtKQVHsoyK and confirm the cause?

Thanks!

2

@Zaheer_Abbas, That’s a documented behavior: “When all of the participants leave the room, the recording would stop automatically” [ RoomComposite & web egress | LiveKit Documentation ]. RoomComposite egress is tied to participant lifecycle, not room lifecycle, so "Source closed" + EGRESS_COMPLETE means the SDK source had no remaining participants to record, even though the room itself was still alive.

Your webhook’s sourceType: EGRESS_SOURCE_TYPE_SDK lines up with that: the SDK source subscribes to participants and mixes their tracks server-side, so when all of them unpublish or disconnect the source closes and the egress completes.

If you need the recording to persist across intervals where the room is empty, the same page names Web egress as the alternative that operates independently of room lifecycle. The trade-off is you configure the stop condition explicitly on that path rather than relying on a participant-leave default.

For the session-specific lookup (EG_uQZWiVdrzcrv / RM_AEHtKQVHsoyK), that needs a Cloud support ticket, forum-side help can’t pull those server logs.

3

“When all of the participants leave the room, the recording would stop automatically”

@Muhammad_Usman_Bashir - I have mentioned that the participants were still present in the Room and egress was closed automatically.

Would appreciate if you can help check what went wrong here.

4

This is a strange issue. To me, it looks like the Egress closed because it was no longer receiving track data (even though the tracks were still present). I don’t see any other reports of similar issues around this time, so I’m unsure of the root cause. I hope Milos can add his expertise to this thread.

5

Thanks @darryncampbell , I have requested @Milos_Pesic to check once too.

Appreciate the help.

6

It could be the Life Expectancy of the Key generated, or authentication token for the user. Just a guess, because I had this occur during an interview, and I was using Ingress to push to my room, with Egress multicasting to my social platforms. After an hour it dropped, and it was due to my Authenitcation token, and my guest. Once we logged out and logged back in, it went good. So, I raised the Life Expectancy of my tokens, and I have had no issues.
I pull my guest into obs with browser source, and mix them in OBS Studio, and use Ingress to push us both back to the room. Then, I use egress to grab the room, with track_composite, and multicast to my social platforms. Or, I use Egress just to record the Interview on my server, for later playback. That is more for testing, since I record in OBS too. I’ll run one later, and see what I come up with for ya. Just to help me understand it too.

7

@DoC_DiD_iT, With participants still present, the participant-lifecycle reason for “Source closed” doesn’t apply here. Darryn’s read is the one to follow: tracks present, no data flowing. That fits the symptom cleanly, the egress stopped receiving media even though the room stayed alive. The root cause will come from server logs against the egress ID, which is a Cloud-side dig.

While you wait, two data points would help narrow it:

  • Whether the publisher has silence suppression / DTX enabled (some SDKs stop sending RTP during silence, which egress can read as “no track data”), and

  • Whether there’s a track unpublish/republish event near the “Source closed” timestamp.

9

Sorry, my last reply to to something I thought was on another Topic. The Server Logs will tell it all. If Egress gets the source closed, or no one in the room, it will close the connection. I have noticed that. Great points Muhammad Usman Bashir, and thank you for you time. I live in the logs…