This message was deleted.

Everything else is working perfectly with livekit. If a second user joins the session it can see and listen everything correctly. The only thing failing is the recording, regardless if there are 1 or multiple users.

Hey Ricardo, From what I can tell so far, it seems to be able to happen at any point during vp8 video track egress, and it just started happening 3 days ago. It’s possible that this is a connection quality related issue with a recent cloud deployment, so this will take some more investigation on our side. I’ll let you know what I find

alright thank you. For what is worth once I changed my client-side room instantiation things got a bit more stable. At least room egress seems to be recording more consistently. Not sure if it had any impact or was coincidence. Changed to:

const room = new Room({
		dynacast: true,
		videoCaptureDefaults: {
			resolution: VideoPresets.h720.resolution
		},
		publishDefaults: {
			screenShareSimulcastLayers: []
		}
	});

Something in common with all the failures is that the track is momentarily dropped 3 seconds before the egress failure. Have you been seeing any connection issues? (Either way, egress should be able to handle this, so I think there is still something that needs to be fixed on our end)

didnt notice any connection drop, the call seems to be perfect when multiple peers are connected. just fails on egress part

Just created one here https://github.com/livekit/egress/issues/210

Just to be sure, this includes Room Composite egress? Cause in the case of room egress it doesnt explicitly fail, but the recording ends just a few seconds after it starts. In the logs above you can see that the room egress participant leaves as soon as other participant joins. Maybe they are two separate issues.

it’s possible that’s related - room composite completes once the room is empty, so if there are temporary connection issues (even if it only lasts <100ms), and only one participant in the room, it might see that the room is empty and disconnect

Since I create the room in the backend, and only then the first user joins on the frontend, is that interval enough for the recording to be aborted? Or is there a bigger interval when waiting for the first user to join? But that would explain why in my local machine the recordings usually go through (less overall latency and therefore the first user joins faster after the room creation), but when testing in staging it happens a lot that the room egress ends immediately.

it will wait as long as it needs until the first user joins, but I meant that after they join, any momentary disconnection (even if it’s not visible to end users) might make egress think the room is empty. Since that seems to be the issue with the failed track egresses as well, I’m guessing that’s what’s happening

alright, thank you. I'll not bother you anymore and just subscribe the github issue