The suspected cause has been identified, so I would like to report it.
Both Account A and Account B have contracted Zoom Webinars capable of sustaining 30-hour events.
Both accounts streamed video and audio for 7 hours using IZoomSDKVirtualAudioMicEvent and IZoomSDKVirtualAudioMicEvent.
Account A, which successfully completed the 7-hour stream, obtained the Webinar ID via URL Zoom home page webinar.
The logs at that time were as follows:
IZoomSDKVirtualAudioMicEvent::onMicStartSend
IZoomSDKVideoSource::onStartSend
…
[My Application is End]
Meanwhile, Account B, which could not complete the 7-hour broadcast, obtained the Meeting ID at URL Zoom home page meeting.
The logs at that time are as follows:
IZoomSDKVirtualAudioMicEvent::onMicStartSend
IZoomSDKVideoSource::onStartSend
…
IZoomSDKVirtualAudioMicEvent::onMicStopSend
IZoomSDKVirtualAudioMicEvent::onUninitialized
IZoomSDKVideoSource::onStopSend
IZoomSDKVideoSource::onUninitialized
…
[My Application is End]
Unexpectedly, IZoomSDKVirtualAudioMicEvent::onUninitialized and IZoomSDKVideoSource::onUninitialized were called,
causing the application to lose the ability to send video and audio mid-session.
The timing of these calls also varied significantly.
Sometimes they were called after about 40 minutes, while other times they were called after 4 hours had passed.
In other words,
even though it’s a paid account capable of webinars, when running in meeting mode,
midway through,
IZoomSDKVirtualAudioMicEvent::onUninitialized and IZoomSDKVideoSource::onUninitialized are called,
causing the application to be forced to close.
Is this intended behavior?
Or is it a bug?
I would appreciate your response on this point.
>there should be some logs at ~/.zoomsdk/logs/
I confirmed they exist.
The header of the latest file contained the following fields.
What information should I provide?
ReceiverVersion:CSV30
CipheredPassword: …
CipherSignature: …
LoggerInfo: …
FileInfo: ..
ClientVersion:6.5.10.4407
ProductType:LINUX_SDK
End
…