I have an issue that livekit events are not raised properly i.e., during few sessions, some events are not raised.

Thanks for reaching out, Sailendra. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

if a participant is not enabled for publishing, whatever we return will it be passed in the session

Thanks — I’m responding to your question about whether data (or events) from a participant who is not enabled for publishing will still be passed in the session. Short answer: • If a participant is not publishing (i.e., they have not published tracks or been promoted to a publisher), they will generally not generate publish-related events (like

track_published

) and will not appear as a publisher in remote participant lists. In Livestream Mode (large-room optimization), viewer/subscriber participant events are intentionally suppressed — only publishers trigger participant events. So whatever you “return” as publication-related data for a non-publishing participant will not be propagated as a published track or cause publish events in the session. Clarifications and what this means for you: • Participant metadata that you set on the server for a participant (outside of published tracks) can still exist in the server’s participant record, but it won’t produce the same real-time publish/track events if the participant never publishes. • If your application relies on receiving participant lifecycle events for every connected user (including non-publishers/viewers), Livestream Mode will prevent those events for viewers; only publisher participants will fire those events. • For audio/video/data channels specifically: if the participant hasn’t actually published tracks or opened a data channel, those streams/notifications are not delivered to other participants as published media. If you want me to recommend a concrete approach, tell me: • Are you using Livestream Mode for these rooms? • Which SDK/platform are you on (JS, Flutter, iOS, Android)? • Are you trying to send non-media data (custom metadata or data channel messages) from a non-publishing participant? With those details I can suggest one or more options (for example: promoting participants to publisher when they need to send data, using server-side metadata to broadcast state, or using data channels where supported).

oky why track_subscribed is missing

Thanks — I’m following up on your question about why

track_subscribed

is missing. I’ll walk through the most likely causes and give a short checklist so you can quickly triage. If you share a couple of details after this, I’ll give targeted steps. Quick summary of likely causes • Livestream Mode: If the room uses Livestream Mode (skip-subscriber-broadcast), viewer/subscriber participant events are suppressed. Tracks from non-publishing viewers may not trigger

track_subscribed

. • Event listener timing: If you add listeners after connecting, you can miss events. Listeners should be registered before calling

connect

. • Auto-subscribe disabled: If auto-subscribe is turned off, your client won’t automatically subscribe to remote tracks and therefore won’t receive

track_subscribed

. • Track publication/subscribe timing:

track_subscribed

only fires when a remote participant publishes a track and your client successfully subscribes to it; timing differences can make it appear missed. • Platform/plugin issues or connection problems: On some platforms (e.g., Flutter iOS with plugin conflicts) or during WebSocket/TURN failures, events can be lost or not emitted. Short checklist to run now 1. Confirm whether the room is in Livestream Mode. If yes, expect suppressed events for viewers. 2. Verify you register event listeners before calling

connect

(example below). 3. Check your room/client settings for

autoSubscribe

(ensure it’s enabled if you expect automatic subscriptions). 4. Log related events to see the sequence:

participantConnected

,

trackPublished

, and

trackSubscribed

. 5. Inspect client and server logs for connectivity errors or platform exceptions (e.g.,

MissingPluginException

on iOS, or capture queue errors for custom audio sources). Example: register listeners before connect (JS)

room.on(RoomEvent.trackSubscribed, (track, publication, participant) => {
  console.log('trackSubscribed', publication.trackSid, participant.identity);
});

await room.connect(url, token);

What I need from you to dig deeper • Is Livestream Mode enabled for the affected rooms? • Which SDK and exact version are you using (JS/Flutter/iOS/Android)? • Does this happen for all remote tracks or only some participants/platforms? • A short log snippet that includes

participantConnected

,

trackPublished

, and any errors around the time

track_subscribed

is expected. If you share those details I’ll: • Identify the most likely root cause (e.g., livestream suppression, listener timing, or auto-subscribe config). • Provide exact code or configuration changes to fix it. • Offer targeted debugging commands/log checks. Thanks — share the SDK/version and a short event log and I’ll help you pinpoint and resolve this. Sources: Livestream Mode | client-sdk-flutter | livekit/livekit_composite | DeepWiki | examples/other | livekit/livekit_composite | DeepWiki

it was participant joined, track published

Thanks — you’ve clarified that you see

participant_joined

and

track_published

, but

track_subscribed

is missing. I’ll help you narrow this down and suggest targeted checks. Why this pattern can happen • If you see

participant_joined

and

track_published

, the participant and their publication are reaching the server.

track_subscribed

can still be missing if your client never actually subscribes to that published track (or if subscription notifications are suppressed by configuration or a timing/connection issue). Immediate checks to run 1. Confirm Livestream Mode ◦ Is the room using Livestream Mode (skip-subscriber-broadcast)? If yes, subscription events for viewer/non-publisher participants can be suppressed. Only publishers will be broadcast to others. 1. Verify auto-subscribe ◦ Check your client/room settings. If

autoSubscribe

is false, your client won’t automatically subscribe to published tracks and

track_subscribed

won’t fire. Enable auto-subscribe or call subscribe manually. 1. Ensure listener registration order ◦ Make sure you register

trackSubscribed

listeners before connecting to the room. Otherwise you can miss the event if the publish/subscribe happens during connect. 1. Log surrounding events and statuses ◦ Log

participantConnected

,

trackPublished

, and any subscribe-related errors. Also log the publication’s `subscribed`/`isSubscribed` state if available. ◦ Example sequence to inspect: ▪︎ participantConnected -> trackPublished -> (attempt subscribe) -> trackSubscribed ◦ If there’s no “attempt subscribe” step, your client likely didn’t try to subscribe. 1. Check client-side subscribe failures ◦ Look for errors or warnings when subscribing (permission errors, signaling failures, or TURN/WebRTC issues). Network or signaling problems can prevent the subscribe flow even though publish succeeded. 1. Verify participant role/type ◦ Confirm the publishing participant is actually a publisher (has published tracks or set metadata). In Livestream Mode, viewers might not be visible to subscribers. What I need to give you exact steps • Which SDK and exact version are you using (JS, Flutter, iOS, Android)? • Is Livestream Mode enabled for the affected room(s)? • The client-side logs showing the sequence around

trackPublished

(including any subscribe attempts/errors). • Your `autoSubscribe`/connection config and the code where you register

trackSubscribed

. If you share those details I’ll: • Show the exact code change or config to ensure subscriptions occur (or how to subscribe manually). • Point out any platform-specific pitfalls (for example Flutter iOS plugin issues or network checks). • Provide targeted log checks and what specific errors to look for. Send the SDK/version, room mode, and a short log snippet and I’ll guide you step‑by‑step to resolve the missing

track_subscribed

.

ok, if a participant did not subscribe, but publishes a track will it be audible top others

Good question — thanks for clarifying. I’m responding to whether a participant who publishes a track but does not subscribe to others will have their published track audible to other participants. Short answer: • Yes. If a participant publishes a track, that published track is sent to the server and can be delivered to other participants who are subscribed to it. A publisher’s ability to publish is independent of whether they themselves subscribe to other participants’ tracks. Key points to keep in mind • Publishing vs subscribing are separate actions: ◦ Publishing: sending your audio/video/data to the room. ◦ Subscribing: receiving others’ published tracks. • If you publish an audio track, other participants who are subscribed to that publication will receive and hear it, even if the publisher has not subscribed to anyone else. • Whether other participants actually hear the track depends on their subscription state: ◦ If auto-subscribe is enabled on their clients, they’ll typically receive your published track automatically. ◦ If auto-subscribe is disabled, other clients must explicitly subscribe to your publication to receive audio. • Room modes matter: ◦ In Livestream Mode (skip-subscriber-broadcast), viewer/subscriber participant events can be suppressed. However, published tracks from publishers are still available to subscribers/publishers as allowed by the room configuration — the suppression affects event notifications, not the fundamental ability to publish audio. • Network/signaling issues or subscription failures on client side can prevent others from receiving the published track even though it was published (so check subscribe success and logs if others report they can’t hear you). If you want, I can: • Walk you through verifying subscribe state on a client (code snippet for your SDK). • Help check whether auto-subscribe or Livestream Mode is affecting delivery in your rooms. Tell me which SDK/version you’re using and whether auto-subscribe or Livestream Mode is enabled, and I’ll give exact checks or code to confirm.

ok, but on one participant publishing should enable other to subscribe to that track

Thanks — I’m following up on your confirmation: you expect that when one participant publishes a track, other participants should be able to subscribe to that track. That expectation is correct. I’ll summarize the behavior and give the practical checks to ensure subscribing actually happens. What should happen • Publishing and subscribing are independent: when a participant publishes an audio/video track, that track is made available on the server for other participants to subscribe to. • Other participants will receive (and hear/see) the published track if they subscribe to it. If auto-subscribe is enabled on their client, they usually get the track automatically. • A publisher does not need to be subscribed to others for their published track to be subscribable by others. Why subscribing might still not occur (quick checklist) • Auto-subscribe is disabled on the subscribing client, so it never automatically subscribes — you must call subscribe manually. • Your subscribing client never attempts to subscribe because the

track_subscribed

listener was registered too late or subscription logic didn’t run. • Room is in Livestream Mode: events for viewers/subscribers may be suppressed; ensure participants are publishers if you expect full lifecycle notifications. • Network/signaling failures or permission/role restrictions prevented the subscribe request from succeeding. • Platform-specific issues (e.g., plugin conflicts on mobile) disrupted the subscribe flow. Practical checks to run now 1. Confirm the publishing participant shows

trackPublished

on other clients’ logs. 2. Verify the subscribing client’s

autoSubscribe

setting. If false, explicitly call subscribe on the publication. 3. Register and log these events in order before connect: ◦

participantConnected

/

participantJoined

◦

trackPublished

◦ Attempt/response to subscribe ◦

trackSubscribed

1. Look for subscribe errors in client logs (permission, signaling, or ICE/TURN failures). 2. If you use Livestream Mode, confirm roles (publisher vs viewer) for the participants involved. If you want, I can provide exact code snippets for your SDK to: • Check publication state and call subscribe manually, or • Log and surface subscribe errors. Tell me which SDK and version you’re using (JS, Flutter, iOS, Android) and whether auto-subscribe or Livestream Mode is enabled, and I’ll give the precise snippet and next steps to validate subscriptions.