Screen sharing fails since december server update

Hi all,

I have been running self-hosted jitsi for a couple of years, but after updating to the latest version in December, screen sharing has not been working well.

It seems to be something about my server, because on it works well.

With my server, it works fairly well with Firefox, but with the jitsi electron app it doesn’t work at all. If a user shares his screen, other users see the UI switch as if screen sharing is starting, but they just see a black screen (or sometimes the last frame from the user’s camera).

Anyone else seeing this? How can I debug this?

I’m running:

jitsi-meet             2.0.6826-1          
jitsi-meet-prosody     1.0.5764-1          
jitsi-meet-turnserver  1.0.5764-1          
jitsi-meet-web         1.0.5764-1          
jitsi-meet-web-config  1.0.5764-1          
jitsi-videobridge2     2.1-607-g153f7e4e-1 
jicofo                 1.0-840-1           

Did you maybe try clearing the cache in your electron app? Not sure if that could perhaps help.

How do you clear the cache? I don’t think it’s that though, it also fails in a Chromium incognito window.

Ah, if it fails in Chromium incognito, then it’s not the cache.
Strange that it works on Firefox but not on Chrome. :thinking: Do you see any errors in your js console?

The issue may be related with old config files. Did you purge all Jitsi related packages before upgrading?

On Firefox it “works”, as in: screen sharing starts, other users can see it, image quality is good, but then after a minute or so it will stop updating, then go blank, then start working again. It’s flakey. But debugging the Chromium/Electron issue seems a better place to start, since it never works. Tried Chromium, Chome, Electron app, Mac, Windows, Linux. Never works. I’ve never checked a “js console” before, but I’ll do some googling on that…

The issue may be related with old config files.

That’s a thought… You mean the file /etc/jitsi/meet/

Did you purge all Jitsi related packages before upgrading?

No. I did a typical:

sudo apt-get update
sudo apt-get -V upgrade

Another thing to note: this occurs in a very simple scenario of just two participants on the same gigabit ethernet LAN, on the same switch even. No wifi, no internet traversal, etc.

Are you able to successfully host a 3-party meeting?

Are you able to successfully host a 3-party meeting?

Yes, we’ve had meeting with all our employees, about 20. It’s just screensharing that’s broken.

Ok. Did you see anything in your browser’s js console? And what about using the latest default config.js and interface_config.js?

I’m currently diffing config.js from git master vs mine. There are a great many differences, mostly comments, but I’m now merging them by hand…

There sure have been many changes! The only things I’m not sure how to merge is near the top, line 21:

git master:

        muc: ''


        muc: 'conference.<!--# echo var="subdomain" default="" -->'

Not sure how mine got to look like that. My installation notes don’t mention it, so I don’t think I did it.

No, that’s the Debian installer. It’s for managing subdomains with Nginx, something that is not relevant at the source code level (git). You can leave it as it is or remove it since with 20 users you are not likely to have a need for subdomains (something used for tenants).
And please try to use Chrome for a test, while opening Dev Tools (More Tools menu), then click the Console tab, and use right clic to save as… . Then upload the file here.

Thanks for pointing to me the console. With Chromium, here are the logs starting from when I press the ‘start sharing your screen’ button (I edited out what looks like very verbose backtraces):

Logger.js:154 2022-01-27T00:26:30.518Z [modules/RTC/ScreenObtainer.js] <Object.obtainScreenFromGetDisplayMedia>:  Using getDisplayMedia for screen sharing {video: true, audio: true, cursor: 'always'}
Logger.js:154 2022-01-27T00:26:33.064Z [JitsiConference.js] <jc._doReplaceTrack>:  _doReplaceTrack - no P2P JingleSession
Logger.js:154 2022-01-27T00:26:33.112Z [modules/RTC/TraceablePeerConnection.js] <ha.setSenderVideoConstraints>:  TPC[id=1,type=JVB] Setting degradation preference [preference=maintain-resolution,track=LocalTrack[6,video]
Logger.js:154 2022-01-27T00:26:33.114Z [modules/RTC/TraceablePeerConnection.js] <ha.setSenderVideoConstraints>:  TPC[id=1,type=JVB] setting max height=2160,encodings=[{"active":false,"adaptivePtime":false,"maxBitrate":500000,"networkPriority":"low","priority":"low"},{"active":false,"adaptivePtime":false,"maxBitrate":500000,"networkPriority":"low","priority":"low"},{"active":true,"adaptivePtime":false,"maxBitrate":500000,"networkPriority":"low","priority":"low"}]
Logger.js:154 2022-01-27T00:26:33.115Z [modules/xmpp/JingleSessionPC.js] <Object.callback>:  JingleSessionPC[session=JVB,initiator=false,sid=8mupq9rcdqp77]  Replace track done!
Logger.js:154 2022-01-27T00:26:33.135Z [features/base/tracks] Replace video track - unmuted
Logger.js:154 2022-01-27T00:26:33.159Z [conference.js] Screen sharing started
Logger.js:154 2022-01-27T00:26:37.236Z [modules/RTC/BridgeChannel.js] <Kr._send>:  Bridge Channel send: no opened channel.
Logger.js:154 2022-01-27T00:26:37.237Z [JitsiConference.js] <Qa.sendMessage>:  Failed to send E2E ping request or response. undefined
Logger.js:154 2022-01-27T00:26:40.549Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onclose>:  Channel closed by server
Logger.js:154 2022-01-27T00:26:40.550Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onclose>:  Channel closed: 1006 

Could you paste your Nginx config?

if you are afraid of spamming the forum with huge cut & paste, it’s a worthy consideration, however there is also the upload button for bigger amounts of text. I for one love verbose backtraces, sometimes among all the verbiage there is a grain of truth :slight_smile: so please post the whole thing.
I just tried the Jitsi Electron client, not changed much since last time, it just zapped my preferences again. It has successfully shared my screen (on Ubuntu 18) with another PC running Ubuntu 20 with Chrome snap Ubuntu (97 currently).
On Electron you can display dev tools also, right click the screen and choose Inspect - the only option - the select the Console tab, click the crossed circle or use Ctrl L to clear the previous trace and start sharing).
This reminds me (dimly) of a previous post on this forum where Firefox was the only option, IIRC the problem was coming from the OS configuration, the other browsers were respecting the OS config blocking screen sharing, I think it was Windows. When you say that you tried on Linux were you speaking about the sharing workstation, or the users supposed to see the screensharing ?

Here it is, with only my domain changed to

$ cat /etc/nginx/sites-enabled/ 
server_names_hash_bucket_size 64;

server {
    listen 80;
    listen [::]:80;

    location ^~ /.well-known/acme-challenge/ {
       default_type "text/plain";
       root         /usr/share/jitsi-meet;
    location = /.well-known/acme-challenge/ {
       return 404;
    location / {
       return 301 https://$host$request_uri;
server {
    listen 4444 ssl http2;
    listen [::]:4444 ssl http2;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    add_header Strict-Transport-Security "max-age=31536000";

    ssl_certificate /etc/letsencrypt/live/;
    ssl_certificate_key /etc/letsencrypt/live/;

    root /usr/share/jitsi-meet;

    # ssi on with javascript for multidomain variables in config.js
    ssi on;
    ssi_types application/x-javascript application/javascript;

    index index.html index.htm;
    error_page 404 /static/404.html;

    gzip on;
    gzip_types text/plain text/css application/javascript application/json;
    gzip_vary on;

    location = /config.js {
        alias /etc/jitsi/meet/;

    location = /external_api.js {
        alias /usr/share/jitsi-meet/libs/external_api.min.js;

    #ensure all static content can always be found first
    location ~ ^/(libs|css|static|images|fonts|lang|sounds|connection_optimization|.well-known)/(.*)$
        add_header 'Access-Control-Allow-Origin' '*';
        alias /usr/share/jitsi-meet/$1/$2;

    # BOSH
    location = /http-bind {
        proxy_pass      http://localhost:5280/http-bind;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $http_host;

    # xmpp websockets
    location = /xmpp-websocket {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
        tcp_nodelay on;

    location ~ ^/([^/?&:'"]+)$ {
        try_files $uri @root_path;

    location @root_path {
        rewrite ^/(.*)$ / break;

    location ~ ^/([^/?&:'"]+)/config.js$
       set $subdomain "$1.";
       set $subdir "$1/";

       alias /etc/jitsi/meet/;

    #Anything that didn't match above, and isn't a real file, assume it's a room name and redirect to /
    location ~ ^/([^/?&:'"]+)/(.*)$ {
        set $subdomain "$1.";
        set $subdir "$1/";
        rewrite ^/([^/?&:'"]+)/(.*)$ /$2;

    # BOSH for subdomains
    location ~ ^/([^/?&:'"]+)/http-bind {
        set $subdomain "$1.";
        set $subdir "$1/";
        set $prefix "$1";

        rewrite ^/(.*)$ /http-bind;

    # websockets for subdomains
    location ~ ^/([^/?&:'"]+)/xmpp-websocket {
        set $subdomain "$1.";
        set $subdir "$1/";
        set $prefix "$1";

        rewrite ^/(.*)$ /xmpp-websocket;

Looks like you didn’t migrate to colibri websockets. What version were you running before this upgrade?

I went from:

jitsi-meet            2.0.6173-1          2.0.6726-1         
jitsi-meet-prosody    1.0.5211-1          1.0.5675-1         
jitsi-meet-turnserver 1.0.5307-1          1.0.5675-1         
jitsi-meet-web        1.0.5211-1          1.0.5675-1         
jitsi-meet-web-config 1.0.5211-1          1.0.5675-1         
jitsi-videobridge2    2.1-538-g062e9f56-1 2.1-595-g3637fda4-1

I’ll search about “migrate to colibri websockets” but I’m pretty certain apt-get -V upgrade didn’t output any instructions about manual migrations being necessary…