We see the same here. Was hoping that 1.7.9 would fix, but we still see black screen if someone joins and there is no current screen share (video only). If you share screen and then exit, corrected for all current users, but any new users see black screen until next screen share.
Thank you for sharing feedback that 1.7.9 did not resolve the empty video join issue.
We’ve shared this information with our engineers and they’re investigating the root cause further.
@subscriptions1 @mchrenko @flippyhead @SamHarper @bkirk @eperture.dev @sales1 @qun @developer-whova @vijayk.kannan @conradwalz @mb_j @tnelson @emirgocen @rain-digital @adamk AND anyone reporting the issue of black screen on meeting join with the WebSDK, please share the following data to help us better understand the range and impact of this particular issue please:
TESTING DEVICE DATA: Operating System w/ version, Browser w/ version, and if (mobile/handheld device, the distributor, such as AT&T, etc…). EXAMPLE: macOS High Sierra 10.13.6, Google Chrome Version 83.0.4103.116 (Official Build) (64-bit), MacBook Pro
WEB SERVER DATA: Operating System w/ version (Node, PHP, other…?), Web Server Framework (if applicable, w/ version, such as Express.js v 4.1.2, etc…), How it is hosted (bare-metal, VM, Docker container, PaaS, other), Client-Side Framework (React, Vue, Angular, TypeScript, etc…?) EXAMPLE: Node.js 12.1.6 on Heroku using Express.js v4.11.6 with React.js v15.6
Issue recreation step-by-step directions.
[OPTIONAL, if provided, make sure to anonymize before sharing] Any relevant console, device event, system, warning, or web server logs providing insight you think could be useful.
@bdeanindy details below:
- macOS Catalina 10.15.5, Google Chrome 83.0.4103.116 (Official Build) (64-bit), Macbook Pro
- node.js 12.16.x on Heroku using Express.js v4.14.x with React.js 16.8.6
- Just start a zoom call from the web app, then join from iOS app, the web app user can’t see video from the iOS user, but iOS user can see videos from both.
- Nothing special except for the "
NaNis an invalid value for the
widthcss style property" error which I don’t think is relevant.
Just want to add that for item 2, we have another environment on AWS EC2 (node.js 12.16.x, Express.js v4.14.x, React.js 16.8.6) with the exact same issue.
@bdeanindy I can provide a live instance of this happening right now if you want? And if you want we can pair review it. Let me know, as I can consistently Reproduce with 1.7.8 and 1.7.9 and can get it working fine with 1.7.7 and I can show this live.
I think this is a front end bug in the SDK, my feeling some code executed too early somewhere. I can share a video of the problem also privately, lmk which address I can send it.
I agree this is a front end issue. When the host stops streaming the attendee see the image of a user that appears when no user is stream, and then when back on goes blank.
@darragh.duffy would you be able to provide the information I requested in my previous post please?
Additionally, could you (and @developer-whova) provide your data supporting this is a front-end issue within the WebSDK, to help with the root cause investigation please?
@darragh.duffy May I have a live troubleshooting with us, currently, it’s very hard to reproduce for me.
Yes, I can do a live trouble shoot with you, I am on GMT+1 timezone right now its 10:25am. I can do anytime you. What suits you? I would be delighted to show you this issue.
Hi Zoom Engineers,
Some more examples, here I am showing a few screen shots.
First image, the host is streaming video content - Left screen using v 1.7.7 and right screen v 1.7.8
Second image, the host stops streaming video content - Left screen using v 1.7.7 and right screen v 1.7.8
I am seeing the exact same issue with 1.7.9 (as an aside please allow an option to disable captcha, users will already be authenticated).
When I inspect the the screen via Chrome’s Dev tools, I can see a difference in the Canvas with ID: sv-active-video
In v 1.7.7 - the width has been calculated.
in v 1.7.8 - the width has not been calculated.
For v 1.7.7 the video stream is very stable and always works.
For 1.7.8, very unstable, i.e. works 1 times out of 10.
Now, the time it works with 1.7.8, the width attribute for the Canvas ID sv-active-video is calculated. And, the cases where it is not working, this attribute is never calculated. Therefore, the method / approach to how this is calculated would be where I could review the code.
So, some suggestions:
- do a live troubleshoot session.
- send me the source code so I can debug and help better.
- review the code around calculating the width of this attribute, maybe its as simple as an ASYNC/ AWAIT issue.
Hello Darragh, I invite you join our troubleshooting
this meeting open 20200703 GMT+1 9:am - 11: am
Hi Jack - I will join this webinar in about 5 minutes.
Ok, I’m here, welcome
This is happening on 1.7.9. The only “Fix” we’ve seen is to use 1.7.7. 1.7.8 also has the issue.
This is very bad. Essentially, embedded client is useless with this. I hope somebody from zoom can comment on it and explain.
We also experience this issue since at least version 1.7.7 (included - we did not test with previous versions unfortunately)
- We can reproduce this error 100% of the time by using a high CPU spec chrome box for the host.
- We never reproduce this error with a low CPU spec chrome box for the host.
- The video stream works no matter the bug appear, thus look lilke a UI bug, and a race condition one.
I did not inspect the code but would definitely give a try to @darragh.duffy last comment about async / await depending on what you found during that troubleshooting session.
This is also a critical issue for our business.
I try to join zoom video last two days.
I am used latest version 1.7.9
While join meeting using web sdk I got Black screen.
Please where I did mistake or Mistake from API Side ?
I can say that the Zoom engineers reached out to me. In fairness to them then spent a lot of time with me on Friday last looking at the issue. I now believe they have a solution, I tested a version yesterday 1.7.9.x and it passed all my tests.
Thanks again to the Zoom Engineers to taking the time to run through the issue.