We’re experiencing a random, non-reproducible issue in our live classroom application where all participants’ videos suddenly stop streaming (go black) during an active Zoom Video SDK session whereas audio remains audible throughout.
Platform:
Classroom : We have a React based application which run through Electron-based desktop application and the zoom session is loaded on electron window by passing the meeting url.
This electron app also includes some of the features which involves creating multiple BrowserWindow instance.
Teacher(HOST): We use the React app directly on browser (generally chrome)
**Flow : **
Each participants including teacher publishes their audio & video when joined. but the video feed of classrooms is only subscribed at teacher end and at classroom end only teacher video feed is subscribed.
during the session no one can turn their video off (We don’t have this feature as per our requirement).
But the teacher can mute/unmute classrooms audio, we do so by calling muteAudio() method at classroom side when it receives socket event to mute and unmuteAudio() to unmute.
So from our end we don’t have any code which can turn the video off.
we are also listening to ‘active-media-failed’ event which is not getting triggered when this issue appear.
Could you please help me in debugging this issue?
What all are the scenario in which zoomSDK stops publishing video stream automatically.
We analyzed many Electron users in this session and found that they almost all triggered a device-change at the same time (2025-12-15T11:22:33 GMT), but the retrieved device list was empty.
For microphones and audio speakers, the Video SDK will fall back to using the default devices. However, for the camera, since there is no default device and no available camera device, we proactively stop the video to prevent video exceptions.
As for why device-change was triggered, this could be due to switching WebView instances or another application temporarily taking control of the camera, causing the current WebView to lose media permission temporarily.
The current workaround is to listen to the device-change event and retrieve the camera list. If the video has been stopped but the camera list becomes available again, you can call startVideo to recapture the video.
Thank you for your help in debugging and explaining this case, it’s definitely an interesting one. I’ll implement the suggested workaround and will reach out if I encounter any further issues.