Same here. I think I found at least one of the causes.
It's AV1. The SDP ends up offering AV1 while the AddTrackRequest says vp8/h264, so the server can't build the receiver, the subscription never attaches, and 15s later the watcher gets -2302.
This is what the server logged at the exact moment the tile went black:
rtc/mediatrack.go:409 could not find codec for webrtc receiver
mime: "video/AV1"
codecs: [video/vp8 (with cid), video/h264]
Following it through the bundled livekit-client:
LocalParticipant.ts:882 downgrades videoCodec when the requested one isn't allowed (AV1 to vp8)
LocalParticipant.ts:966 builds the AddTrackRequest from that downgraded value, all good so far
RTCEngine.ts:855 passes the same value to setPublisherCodecPreferences
RTCEngine.ts:890 returns early on if (preferences.length === 0) return;, silently, so the preference is never applied
And once nothing is pinned, Chromium uses its own default order, which puts AV1 first for screen share. The two halves of the publish disagree and nothing warns you.
What fixed it for me (self hosted): dropped AV1 from the room codec allowlist, left opus + H264 + VP8 in enabled_codecs. Server doesn't offer it, Chromium can't pick it, both sides agree by construction. Watching has been solid since.
It doesn't fix the SDK bug though. That silent return is still there, and if the same mismatch ever happens between H264 and VP8 it'll be back.
To be clear it didn't make the error go away completely. Watching behaves normally now, but I still see -2302 once in a while, way more rarely, and I suspect that's something else entirely rather than the codec thing.
Separate thing I'm still hitting: fullscreen on a stream inside a DM (normal private call, not a community voice channel) turns the video gray and the stream dies after a bit. Doesn't happen in community calls. Haven't dug into it yet.
Thread
Comment by @robertoaraujom
And once nothing is pinned, Chromium uses its own default order, which puts AV1 first for screen share. The two halves of the publish disagree and nothing warns you. What fixed it for me (self hosted): dropped AV1 from the room codec allowlist, leftLocalParticipant.ts:882downgradesvideoCodecwhen the requested one isn't allowed (AV1 to vp8)LocalParticipant.ts:966builds the AddTrackRequest from that downgraded value, all good so farRTCEngine.ts:855passes the same value tosetPublisherCodecPreferencesRTCEngine.ts:890returns early onif (preferences.length === 0) return;, silently, so the preference is never appliedopus + H264 + VP8inenabled_codecs. Server doesn't offer it, Chromium can't pick it, both sides agree by construction. Watching has been solid since. It doesn't fix the SDK bug though. That silent return is still there, and if the same mismatch ever happens between H264 and VP8 it'll be back. To be clear it didn't make the error go away completely. Watching behaves normally now, but I still see -2302 once in a while, way more rarely, and I suspect that's something else entirely rather than the codec thing. Separate thing I'm still hitting: fullscreen on a stream inside a DM (normal private call, not a community voice channel) turns the video gray and the stream dies after a bit. Doesn't happen in community calls. Haven't dug into it yet.