This is an expected behavior. When the users join the meeting for the first time, they will be prompted that “this meeting is being recording” by the auto cloud recording.
Subsequent recordings including the ones triggered by mediaCapture, will not re-prompt the users.
I do realise that when auto cloud recording is turned on, the mediaCapturePermission doesn’t trigger a permission prompt to the host. I’ve filed a bug for this.
Sorry @chunsiong.zoom , but I couldn’t understand you correctly. Subsequent recordings as-in? Are you implying that if we toggle auto recording in this sequence ON=>OFF=>ON, then the first meeting conducted would have the prompt played for the participants, but next meetings won’t have it? What’s the rationale behind such implementation?
When you turn on auto cloud recording → all participants joining for the first time will get a recording notification.
If you attempt to call mediaCapture, it will not prompt the recording notification to the participants again.
if we toggle auto recording in this sequence ON=>OFF=>ON, then the first meeting conducted would have the prompt played for the participants, but next meetings won’t have it? What’s the rationale behind such implementation?
if we toggle auto recording in this sequence ON=>OFF=>ON, then the cloud recording in the specific meeting conducted would have the prompt played for the participants, but next recordings won’t have it. The rational is that in an instance of a meeting, stopping recording and restarting recording should not reprompt users multiple times.
Subsequent recordings = recordings which are started after auto cloud recording, in the same instance of meeting
This effect does not roll-over to subsequent meetings.
Hi @chunsiong.zoom
Yeah makes sense now. Thanks for clearing the doubts.
Also the zoom’s sample websdk app currently uses timer logic to call mediaCapture API which is very in-efficient. Perhaps a callback based implementation would be more elegant.
Also another issue is with the different errors of mediaCapturePermissionError. Many errors have same error code numbers, but error description(string) is different. This is again a buggy and unreliable solution to build upon.
I believe these changes wouldn’t take much time to implement and would go a long way in developer community adoption.
What are your thought on this?
This seems like a sample code behavior and serves to demonstrate how the mediaCapture can be called.
While polling might not seem to be elegant, but it has probably serve it’s purpose to demonstrate how it can be called.
In a best case scenario, there are various constrains which needs to be checked, however we do need to have a balance in terms of complexity vs ease of understanding. Some cases which needs to be checked, non exhaustive
is the host already in the meeting
is local recording enabled for the meeting
Many errors have same error code numbers, but error description(string) is different. This is again a buggy and unreliable solution to build upon.
I hear you on this, while this is a relatively new API, the error message can be improved upon. I’ll feedback this to the engineering team. Is there a scenario you would like to share for this feedback?
@chunsiong.zoom ,
Thanks again for your thoughts on the same.
About the error codes, what I found is that same error code=1 was used for successful/unsuccessful response from mediaCapture API in few cases like below where currently we have to handle it like below:
if (error.errorCode == "1" && error.errorMessage === "you already have local record permission") {
console.log( "LOCAL_RECORDING_PERMISSION_PRESENT" );
console.log("Media capture permission Active");
window.ZoomMtg.mediaCapture({ record: "start" });
} else {
console.log( "RECORDING_PERMISSION_ERROR" );
console.log(error, "media capture permission error");
}
Generally speaking, error codes should be unique and only to be used for unsuccessful/failed responses.
Wdyt?
Hey @deepak.babel this is definitely something we’ve run into as well. We work extensively with the Zoom Web SDK to build bots, and have encountered several different edge cases with the error message.
A few situations we’ve seen the mediaCapturePermission function emit different error messages with the same error code are:
Local recording is disabled account-wide
Local recording is disabled for this specific meeting
The bot is in the waiting room while making this request
The host is not present in the meeting
Permission has already been granted
My recommendation would be to try calling the function with the bot/meeting set up in the various permutations, and record the error messages that you receive. In your code you can then classify the error based on the message, as you are correct that the error code returned by the function is always the same.
Keep in mind that whenever you update your Zoom SDK version you’ll need to repeat this manual procedure to verify that the error messages have not changed, and also verify if there are any new error messages that have been introduced.
An alternative is to use the recall.ai service, which is an API for hosted meeting bots. This means you don’t need to run any infrastructure, and we handle these various edge-cases so you can focus on building your core product.
