Error code -2302 watching stream

(#774) Bug Needs triage video voice

Observed behaviour

User starts stream with audio share, error message "Watching failed :( error code -2302"

Reproduction steps

  1. User A starts stream with audio
  2. User B tries to watch stream
  3. 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

Evidence

  • 636700239-2604f64c-1614-42eb-bf5b-0ea48df6fac8.png

    636700239-2604f64c-1614-42eb-bf5b-0ea48df6fac8.png

    2071×1310 | 28 kB

5 comments

Sign in with Fluxer to comment and vote.
Comment by @robertoaraujom
RexSystem 1 vote originally by @robertoaraujom on GitHub
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.
Comment by @Takewi
RexSystem 1 vote originally by @Takewi on GitHub
I can watch my friend's stream, and he has audio sharing turned on, but I can't hear anything. When I try to share my screen with or without audio he gets the error -2202, but he can hear my computer, as if I were only sharing my desktop audio.
Comment by @MoonlightKay
RexSystem 1 vote originally by @MoonlightKay on GitHub
New user, getting -2302 and -2202. Both appear the same way, instantly when starting a stream at any combination of settings. It feels completely random if streaming will work. Not sure how to fix on my end if possible yet.
Comment by @HTGM1
RexSystem 1 vote originally by @HTGM1 on GitHub
i am also having this issue on CachyOS, my hardware is on CachyOS utilizing a RX7600 and this occurs on AV1 and H264 codecs on a receivers end, meanwhile VP9 and 8 shows previews the receiver is on windows 10 IoT 21H2 on a Nvidia RTX 4070 Ti Super i was using H264 at first as it was default, but was trying different ones to see if i could fix it with a different encoder, i then tried updating and then one encoder started working which was VP9, but then every other encoder will show a preview at first, but then error on -2302 after a tiny short bit
Comment by @altpyrion
RexSystem 1 vote originally by @altpyrion on GitHub
Canary Desktop 2026.911.113656, Web 2026.911.234313, Linux 7.1.13-200.fc44.x86_64 (x64), Electron 44.1.1, Chrome 152.0.7977.65, Node 24.19.0, Locale en-US
I am also having issues on Fedora with a 9070. Only V8 allowed for thumbnail previews, other encodings resulted in a "no codec found" error message when trying to stream. V9 and H.265 are always greyed out