[ALERT] Beware of Chrome 92! 🚫

If you haven’t updated your Chrome to the current latest version (v92), DO NOT DO IT! This release of Chrome is rife with breaking problems - both on the client and on the server.

SUMMARY

Here’s a summary of what I’ve observed so far:

  1. Restriction on available web media players - restricts the number of users that can share media (audio/video) in a meeting
  2. Websocket errors - Chrome 92 specifically threw a bunch of nondescript websocket errors
  3. Breaks Jibri - Upgrading to Chrome 92 on Jibri server breaks Jibri
  4. Breaks Screensharing - Breaks screensharing on VP9 (possibly on VP8 too)

Here’s a more detailed recount of my experience:

1. Web Media Players

The devs at Google had this ‘brilliant’ idea to restrict the number of web media players that can be used in a conference. They set the limit at 75 on the web and 40 on mobile devices. If you’re unfamiliar, just think of web media players as the entities that relay audio and video in your conference. Each participant in your meeting uses 2 media players (one for audio and one for video). Additionally, there are other media players that are immediately consumed once a meeting starts (sound notifications e.t.c…). Now, the logic behind the restriction is sound, but the implementation wasn’t the best. If media players are efficiently released when not actually in use (e.g. when audio or video is muted) and reused, then placing a restriction on the number available would make sense (even then 75/40 would be too low). Unfortunately, this is not quite working like that at the moment. So what this means for you is that if your users are using Chrome 92, after a handful of participants in the meeting, they will not be able to receive the audio and video streams of new participants.

2. Websocket

This almost drove me crazy! I was testing a meeting on a handful of clients (5 clients). All but one were running earlier versions of Chrome (including one on Safari). The client that I started the meeting on immediately spurned websocket errors as soon as a second participant joined the meeting! I was stumped because I hadn’t made any changes to my deployment. I went digging nonetheless and my configurations were still fine. I then joined the meeting through the other clients (running earlier versions of Chrome and one client on Safari) and they worked flawlessly - no errors whatsoever, websocket worked as expected. It was then I thought to check what version of Chrome the troubled client was running and lo and behold, it was Chrome 92! I never would have imagined this! Every other client/user worked fine, no web socket errors, but Chrome 92 threw a basket of ill-defined web socket errors! To double-confirm, I downgraded to a previous version of Chrome (even an earlier version of Chrome 92 - Version 1.27.108 Chromium: 92.0.4515.107 (Official Build) (x86_64)) and boom, everything was fine!

3. Recording

CHROME 92 IS THE DEVIL! CHROME 92 KILLS JIBRI!!! :rage: Now this one particularly riled me! This was apparently the first sign but I didn’t realize it was due to Chrome 92. I’d updated all packages on my dev server days before and the upgrades seemed uneventful. Then, days later I tried recording and recording just wouldn’t start! I was getting the near-generic “org.openqa.selenium.WebDriverException: unknown error: DevToolsActivePort file doesn't exist” error, which could refer to any of many things. So, I started debugging, adding and removing flags, manually upgrading Chromedriver to match the upgraded Chrome version on my server e.t.c… yet nothing helped. Then after going through the issues I observed with the clients, I thought to downgrade my server’s Chrome and Chromedriver, and like magic, Jibri rose again from the dead and starting chugging along like the rugged engine it is. Alleluyah!!!

4. Screensharing

Screensharing expectedly uses web media players. So, as noted in the first point, it will be affected. Peculiarly though, even with just a few participants, screensharing appears not to work at all on VP9 according to a report (someone also seemed to report experiencing this even with VP8). I didn’t get a chance to test it myself, but using earlier versions of Chrome proved that it was strictly a Chrome 92 issue as suspected.

There are probably other issues that I haven’t run into yet. So, for your own good, resist the urge to upgrade to Chrome 92 for now.

Google Dev’s Fix
The Google team has promised an update to be rolled out on August 3rd. However, it’s important to note that this update will merely temporarily lift the restriction on web media players (or raise the limits to more reasonable numbers). THIS IS NOT GUARANTEED TO FIX THE ISSUES WITH JIBRI OR WEBSOCKETS! It may, but I don’t know. For this reason, I’d again caution against upgrading to Chrome 92 on your server and on your clients (user’s machines) till we know for a fact.

Suggested Workaround

  1. You can always urge your users to use Firefox or the Jitsi Electron app for the time being. Any non Chromium-Based browser (e.g. Safari) also works.

  2. If you’ve already upgraded Chrome on your server to v92, downgrade it and then mark the downgraded version to hold it from upgrades till it’s confirmed that everything works fine on the latest version.

              `sudo apt-mark hold google-chrome-stable` 
    

Happy Jitsi-ing!

5 Likes

@Freddie Is it possible to PIN this thread as we do in telegram or Whatsapp?

I always use the packages from the distro repo to avoid surprises.
chromium 90.0.4430.212-1 and chromium-driver 90.0.4430.212-1 are in the official Debian Buster repo.

I don’t think it is possible to avoid browser updates in Windows. After some point of time, browsers stopped responding then restarting them is the only way to fix it.

Even if chrome is updated to 92 user can start it with flag
–max-web-media-player-count=1000
However it is not possible for mobile.

Other option is to let them use Firefox.
I had 2 meeting today with about 40 people on self hosted. I had put an alert on login page,but looks like most users ignored.
Some complaint about missing sharescreen and missing audio in between.
Only about 6 - 8 had camera and microphone on. Most had their camera and mic button hidden but mediaplayers are still generated for them.

I meant Chrome on the jibri instance

It’s possible, but will have to be done by @damencho. He’s on a well-deserved vacation right now though. :slightly_smiling_face:

Same here. Ubuntu 20.04 has updated to Chrome 92 though.

That is why Debian is my favorite distro :slightly_smiling_face:

1 Like

:joy: :joy: :joy:

Thank you Freidie for a detailed note.

Here is our experience:

Chome 92 starting failing sceen share even with two participans. Edge woks fine, screen share works for hours without fail. If we downgrade to Chrome 91 it works well. It even works well on Chrome Canary.

What we cant understand is; SS using Chrome 92 on development enviornment do not fail. Surely, There is difference in prosody version and jicofo in production / development.

What could be the reason that Chrome 92 SS does not fail in develpment evn but fails in production.

92.0.4515.107 chrome version is creating issue in SS with vp9 codec.

Chrome version 92.0.4515.131 is resolving the issue with media players by increasing the limit from 75 to 1000.

There was a huge discussion about this topic on google issue tracker about this breaking many multimedia apps.

We noticed the same errors (clients video frozen). However, we did some tests and found that it even fails with older versions of Chrome.

We did some changes in our code (we have our own app built with the js library) to support the deprecation of PlanB (in this commit).

Our code change is:

Screen Shot 2021-08-06 at 10.36.39 AM

We don’t have the problems in jibri (but we don’t use the latest though, we have it pinned).

Could these problems be related to this change to unified plan instead of a specific version of chrome?

I saw some other threads for Firefox in which @jallamsetty was active. Maybe she has an idea?

Thank you so much for all your work jitsi devs! You have created a beautiful system.

What version of jitsi-meet are you using on your deployment ? So many VP9 and SS related fixes have been made in the last month and a half.

It is possible that you have an updated build in your dev env with all the fixes ?

There were more fixes done after that commit. Please try with latest lib-jitsi-meet lib and check if your issues go away.

1 Like

Thank you so much! Will do it

Issue continue to crash of chrome using VP9. With VP8 it all works fine.

Yeah, it’s been noted that there’s a bug in Chrome 92 that’s causing issues with VP9. This has been reported to the google team. In the meantime, you’ll want to stick with VP8, if you must use Chrome.

same crashes here (also on master) with vp9 and latest chrome.

i noticed that my jvb was still doing sctp stuff even though already migrated to using websockets

→ setting sctp to false in jicofo.conf fixed the crashes for me

sctp {
enabled = false
}

*update never mind, still crashing, these are not always prompt.