Thanks for that information. I am pleased to report that I have followed the guidance and my custom client can now connect again, and I can login. But the application is not working properly or in the manner it used to. So some more questions if I may.
By far the most important question is whether there is any limit in the Zoom server as to the maximum number of screen shares that can be rendered simultaneously in a custom sdk client. The purpose of my client is to allow our trainers to watch what the trainees are doing on their remote PC’s whilst training software over Zoom. The old version used to be able to render 10 or so remote screen shares simultaneously and it worked really well. But the updated client can only render two at a time.
Some more information. I am testing using four remote Zoom users/sessions on separate PCs all sharing a different local Windows application on their respective machines. Two of the remote shared applications render perfectly in my client but the other two display as black rectangles. I don’t think it’s a problem with the remote Zoom sessions as I can switch between the individual remote shares in the standard Zoom client, and they all display perfectly. Similarly, I don’t think it’s an issue in my client as the remote sessions can all share perfectly within it, but only two at a time. I can control which two work, by the order in which I start the remote sharing. The first pair to start sharing display perfectly, but the second pair appear to the client to be working fine but actually display as black rectangles. I can pick any two from the four, but only two. I don’t think it is a problem with the software as I never get any error messages, the renderers all appear to be created and running ok, any two of the four connections can work (but only in pairs), and it’s the same code that used to be able to render any number of shares. I have tried running the client on two different PC’s and the behaviour was identical on both (two work, two don’t).
So the obvious question, please, is whether you have introduced a limit in your server as to the maximum number of screen/window shares that can be rendered simultaneously in an custom sdk client. If you have, is there any way of raising it for an individual application? A limit of two is a disaster for the application and would be a major problem for us.
And I have three less important questions that your documentation/web site doesn’t currently answer.
To authorize my client, I have to create a JWT token using the SDK key and secret and send it to the server, and all is well. The type of my client is ‘ Meeting SDK’ although this first step requires the use of a JWT Token. Can you please confirm that despite the use of the token, my application is not a ‘JWT App’ that you will stop supporting in June next year, but a Meeting SDK client that will be okay beyond that date.
The sdk authorization I successfully receive lasts for 1 hour. Towards the end of this period I receive an ‘onZoomAuthIdentityExpired’ event. If I respond instantly by generating a new JWT token and requesting authorisation again, the re-authorisation fails. But if I try again a second later it works. Is this just a matter of your server not being ready because my new request is too quick? Is there a better way to do this?
Similarly, I can now use the OAUTH mechanism to login to Zoom. The Zoom access token I receive also lasts one hour. But in this case, my application never receives any corresponding ‘onZoomIdentityExpired’ event, and so I am using a timer to trigger refreshing the access token. This appears to be working fine, but again, is there a better way to do this?