Observed behaviour
User starts stream with audio share, error message "Watching failed :( error code -2302"
Reproduction steps
- User A starts stream with audio
- User B tries to watch stream
- error message above
Build information
Canary Desktop 2026.816.172808, Web 2026.816.121358, Windows 11 10.0.26200 (x64), Electron 43.4.0, Chrome 150.0.7871.224, Node 24.18.1, Locale en-US
Platform
macOS, Windows, Linux

5 comments
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.Comment by @Takewi
Comment by @MoonlightKay
Comment by @HTGM1
Comment by @altpyrion