This message was deleted.

These are the screenshot. • Image 1 is related to my second question • Image 2 is the screenshot from my dashboard that saying the session has duration (2 mins) but the logging is just 0.

@glamorous-london-8756 there isn't a way to debug the egress service currently. we are working to surface these information in the Cloud dashboard. These changes should be released this week. Looking at the Egress instance themselves, it looks like the issue is your custom template did not log a

START_RECORDING

line. Egress relies on this signal to give applications control over when the recording should be started. (more info can be found here).

@dry-elephant-14928 Thank you for the reply. I see. If it’s going to be released in this week, that’s fine. it's been a bit hard to debug the egress in the LiveKit cloud, so this update will be helpful. Keep up the good work. For the recording, finally it works. It seems there's bug in my app. So, nothing's wrong with the egress. Sorry for the wrong signal. I have more questions • I noticed there is

Track.Source.Unknown

in the livekit sdk. What's it for? • While using room composite, it appears that the egress service isn't listed among the participants. Is there a method to obtain the

participant_sid

on egress, or can we utilize the

egressId

to transmit data of

DataPacket_Kind.RELIABLE

type? I'm using for the reliable type as it's suited for managing huge data in data messages. Currently, I'm using the lossy type to make it works, but it doesn't seem appropriate for transmitting huge data. The transmitted data is related to canvas interactions value and as result, the json value lengthens over time. any suggestions or solutions for this?

Glad you've figured it out. Unknown can be used if you are doing something really custom, and don't think any of the existing sources work out. Hmm, because the Egress participant is hidden, it'll not be possible to see it. However, we do want to enable targeted broadcasts by sending a data message by

participantIdentity

instead (which is the

egressId

. If you are interested in contributing to that, let me know! Are you trying to send the latest state? or are you trying to send a history of the interactions?

I see. Noted.

If you are interested in contributing to that, let me know!

Honestly, I'd like to take a look at it, but I'm not familiar with Go language that is used by egress. Therefore, I plan to check it out a bit later.

Are you trying to send the latest state? or are you trying to send a history of the interactions?

To put it simply, in a recording session, we want to capture various aspects like chat messages, annotations made using the canvas, and more. All of this involves sending data messages though since we can't use anything other than that. Or can we use

Source.Unknown

for canvas or whiteboard or something similar to that? Just curious, if we upgrade the plan into standard plan, is there any upgrade limit for the data message length? We tend to send a long data and for example, base64 image.

I see, using data messages should be fine for that purpose. But it should be able to use any tooling that your normal application would use. I think in this case, you can send each chat message individually, without having to send all of the previous state repeatedly. To answer your question, there are no hard limits on the size of data messages. We do have folks that are sending files through data channels.. Though practically, data channels are designed for smaller payloads (think <100KB)

I see. Noted. Other question, is there way we could get a report or some analytics about data message usage from the dashboard? It would be super useful to have, especially because we'll be using data messages for so many things. Having some sort of log for data message could help us alot as well.

All of the data is consolidated in the participant and room session pages. Though it's not separating out media vs data. One way to isolate data is to try starting a session without transmitting any media.

I see. Noted. Maybe last questions, what's the case for

CONNECTION_QUALITY.UNKNOWN

? Is that indicator to tell a participant is trying to reconnect to the room or something else?