Teams-for-linux: Screensharing stopped working

Created on 12 Jan 2021  路  44Comments  路  Source: IsmaelMartinez/teams-for-linux

Some when over the weekend - between Friday, January 8th, 14:00 UTC and Monday, January 11th 08:00 UTC, screen sharing stopped working for me. When I share a screen, the app behaves like if it would work, but other participant in the call only see my persona icon, instead of the shared screen.
I uninstalled/reinstalled teams-for-linux already, that didn't fix the issue.
I also tried the official Teams client from MS, but that app shares only whole screens instead of individual applications, like Ismael's teams-for-linux.
This applies to the RPM release 1.0.5, teams-for-linux-1.0.5.x86_64.rpm.

To Reproduce
Steps to reproduce the behavior:

  1. Start teams-for-linux
  2. Start a call
  3. Click on the "Open share tray" button
  4. Select a screen or application to share

Expected behavior
Other participants on the call should see my shared application or screen.

Screenshots
None, as nothing is to be seen.

Desktop (please complete the following information):

  • OS: Fedora release 33 (Thirty Three) running with XOrg (not Wayland)
  • Installation package teams-for-linux-1.0.5.x86_64.rpm
  • Version 1.0.5
bug help wanted ready

Most helpful comment

well, looks like they have changed the screensharing functionality on the browser, what probably means they have disabled the plugging they use to require.

I am not sure when I will be able to dedicate time on this but I suspect it will imply removing all the hacky work we did for the screensharing. This might be good news in general as might mean we can migrate to newer versions of electron.

All 44 comments

It is broken for me as well:
I've built it from source from current develop branch (7649cac), reinstalled it and purged configuration folder. No success.

Desktop

  • Debian _testing_, Gnome
  • Version 1.0.6

well, looks like they have changed the screensharing functionality on the browser, what probably means they have disabled the plugging they use to require.

I am not sure when I will be able to dedicate time on this but I suspect it will imply removing all the hacky work we did for the screensharing. This might be good news in general as might mean we can migrate to newer versions of electron.

I have test it in a laptop and works fine for me... what is puzzling. Does the wee pop up show what you are trying to share?

Sorry, limited time but I will see if I can have a wee look on Friday, but is a bit of a pain as I need to do it in a virtual machine as I am in a Mac this days. (company decision)

Simply to add my voice: I have the exact same problem with the 1.0.5 snap version under ubuntu 18.04. I don't get any error message, the pop-up shows what I selected to share, people on the other side see my icon changing as if I'm going to start sharing, but nothing goes through. I have tried to revert any possible change to my system I could think of and tested several time, no luck. I'll gladly help as much as I can to help figure out the fix with my limited nodejs knowledge. Just let me know.

On my end, everything _looks_ exactly as before, but it does not work. I select what to share as normally, but the others can't see my screen. Noticed it on Monday morning (CET).

My initial thought is that MS have removed the need of the plugging (https://chrome.google.com/webstore/detail/microsoft-teams-screen-sh/dhheiegalgcabbcobinipgmhepkkeidk?hl=en) as now some browsers do support the screensharing but is a guess. Again, now I got a Mac (work decision) so I need some time to setup a VM or something to test it.

Maybe try commenting the if in https://github.com/IsmaelMartinez/teams-for-linux/blob/develop/app/browser/desktopShare/chromeApi.js#L7 to see if it goes via another route (when ignoring the plugging). That if was what it then make the angular code in the ms side know that was to go via the plugging so then they pick the source from your client (browser)... maybe is not needed anymore, but just a guess

IsmaelMartinez notifications@github.com writes:

My initial thought is that MS have removed the need of the plugging
(https://chrome.google.com/webstore/detail/microsoft-teams-screen-sh/dhheiegalgcabbcobinipgmhepkkeidk?hl=en)
as now some browsers do support the screensharing but is a
guess. Again, now I got a Mac (work decision) so I need some time to
setup a VM or something to test it.

I tried in chromium 87.0.4280.141, and screensharing does not seem to
work there either. I'm not sure if it did before. This version of
chromium does work to share application windows in jitsi-meet (fwiw).

I tested by trying to record a meeting in teams. One weird thing I
noticed is that video is not recorded or seemingly transmitted to other
clients from chromium or teams-for-linux. I guess there might be some
"cleverness" due to being logged in multiple times as the same user, but
that doesn't really explain the (lack of) recording.

I tried with the chrome teams screen share extension installed in my
browser and without, and it doesn't seem to make a difference.

d

Hello,

Rirstly the work you have done to get teams on Linux is really good, I have been using it on debian and it works better then MS version.
I have also had the same problem screen sharing, in the mean time I temporarily switched to just using the web interface with chrome, my desktop is using Wayland so the screen sharing only worked with X11 application but I found this article https://soyuka.me/make-screen-sharing-wayland-sway-work/ and did this:

In Chromium, you can enable it using the enable-webrtc-pipewire-capturer flag (in chrome://flags)
Now I can do full screen sharing (in chrome) which is nice.

I hope this helps and would love to see team-for-linux working again.

Regards,
Muncjack
PS. I would love to help, but I am not a developer

Can one of you then try running with that flag on?

teams-for-linux --enable-webrtc-pipewire-capturer

or

teams-for-linux --js-flags="enable-webrtc-pipewire-capturer"

if that is the case we can enable it by default by adding it as we do in here https://github.com/IsmaelMartinez/teams-for-linux/blob/develop/app/index.js#L11

Didn't work on my machine. I get this output :

$ teams-for-linux --enable-webrtc-pipewire-capturer
configPath = /home/xxx/.config/teams-for-linux
configFile = { closeAppOnCross: true }
processArgs [ '/opt/teams-for-linux/teams-for-linux',
  '--enable-webrtc-pipewire-capturer' ]
did-finish-load
did-finish-load
[14220:0119/121417.165732:ERROR:adm_helpers.cc(73)] Failed to query stereo recording.
[OpenH264] this = 0x0x2dfbd9761cf0, Warning:Change QP Range from(0,51) to (12,42)
[OpenH264] this = 0x0x2dfbd9761cf0, Warning:Change QP Range from(0,51) to (12,42)
[OpenH264] this = 0x0x2dfbd9761cf0, Warning:Change QP Range from(0,51) to (12,42)
[OpenH264] this = 0x0x2dfbd9761cf0, Warning:Actual input framerate 23.181454 is different from framerate in setting 17.000000, suggest to use other rate control modes
[OpenH264] this = 0x0x2dfbdb5d75d0, Warning:ParamValidation(), AdaptiveQuant(1) is not supported yet for screen content, auto turned off
[OpenH264] this = 0x0x2dfbdb5d75d0, Warning:ParamValidation(), BackgroundDetection(1) is not supported yet for screen content, auto turned off
[OpenH264] this = 0x0x2dfbdb5d75d0, Warning:bEnableFrameSkip = 0,bitrate can't be controlled for RC_QUALITY_MODE,RC_BITRATE_MODE and RC_TIMESTAMP_MODE without enabling skip frame.
[OpenH264] this = 0x0x2dfbdb5d75d0, Warning:Change QP Range from(0,51) to (26,35)

I think the relevant part is : AdaptiveQuant(1) is not supported yet for screen content, auto turned off.

can you try with the "js-flags"? not sure if you might need to run it from source and edit/add it to that https://github.com/IsmaelMartinez/teams-for-linux/blob/develop/app/index.js#L11

IsmaelMartinez notifications@github.com writes:

Can one of you then try running with that flag on?

teams-for-linux --enable-webrtc-pipewire-capturer

I also tried it, with no effect. I had the impression that pipewire was
for wayland. I'm running i3/X11 here, but I suppose I could try to
enable pipewire if there was some chance of it working.

d

can you try with the "js-flags"? not sure if you might need to run it from source and edit/add it to that https://github.com/IsmaelMartinez/teams-for-linux/blob/develop/app/index.js#L11

I added at line 14 this line of code:

app.commandLine.appendSwitch('enable-webrtc-pipewire-capturer');

The screen sharing still don't work on my Ubuntu 20.10.

Tried with the command line flags (ubuntu 18.04) => No luck either.

Hi!

I just wanted to add my experience here: using this client v1.0.5 stopped working, but chromium v87.0.4280.141 does work.
I'm using Manjaro Linux (GNOME) on an Intel/Nvidia system (proprietary driver, switchable graphics), everything is up-to-date.
Display server is xorg-server 1.20.10.

Best regards
Josef

PS: the switchable graphics does work, but is currently not used (everything is running on Intel).

josefschabasser notifications@github.com writes:

Hi!

I just wanted to add my experience here: using this client v1.0.5 stopped working, but chromium v87.0.4280.141 does work.
I'm using Manjaro Linux (GNOME) on an Intel/Nvidia system (proprietary driver, switchable graphics), everything is up-to-date.
Display server is xorg-server 1.20.10.

Best regards
Josef

PS: the switchable graphics does work, but is currently not used (everything is running on Intel).

Just to confirm, screensharing works for you with chromium
v87.0.4280.141? I just tried 87.0.4280.141-0.1 on Debian. Audio / video
works, but not screensharing.

d

Yes, it worked on a call today. With the unofficial client, all I got was a black screen, with Chromium it worked.
I checked it again with chromium v87.0.4280.141:
Audio: works
Camera: works
Screen sharing: works

josefschabasser notifications@github.com writes:

Yes, it worked on a call today. With the unofficial client, al I got was a black screen, with Chromium it worked.
I checked it again:
Audio: works
Camera: works
Screen sharing: works

Thanks for the reply. I just checked with google chrome
88.0.4324.96, and screensharing works there for me.

David Bremner david@tethera.net writes:

josefschabasser notifications@github.com writes:

Yes, it worked on a call today. With the unofficial client, al I got was a black screen, with Chromium it worked.
I checked it again:
Audio: works
Camera: works
Screen sharing: works

Thanks for the reply. I just checked with google chrome
88.0.4324.96, and screensharing works there for me.

Screensharing also works with Chromium 88.0.4324.87 (snap, on Debian).

I have no idea then. I guess worth checking that is not a system update (from around 10 days ago) that made this stop working?

I will continue investigating when I get some time for this. Apologies but ain't easy getting time almost for anything this days for me.

Did some more debugging and it does look like it is still going via the ms plugging.

If the browser now works (for version 88, etc), the change required might be editing the userAgent and maybe removing the extension work.

To try another user agent you should be able to pass the arguments as explained in the config page. You might need to clean your cache. You can find what is your user agent (for the browser that works) going to this website (or similar ones)

Hope helps! I will see when/if I can spend more time on this during this weekend but it is looking unlikely. Appreciate any help you guys can provide. Thanks in advance!

~Dumb question, but how can I clean the cache of this app?~
Nevermind, found it. But why is it in ~/.config/teams-for-linux/Cache?
Shouldn't it be in ~/.cache/teams-for-linux?

it might depend on the installation. in my case I use to remove the full ~/.config/teams-for-linux folder.

the config folder location info we gather is in here https://github.com/IsmaelMartinez/teams-for-linux/blob/develop/KNOWN_ISSUES.md#config-folder-locations but it might be out of date? You can always remove both.

I just tested

teams-for-linux --chromeUserAgent "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36"

I confirmed the new useragent is in use by inspecting headers using in-app dev tools.
Changing the user agent didn't help, though.

@josefschabasser, thanks for checking. Does that browser allow you to do screensharing? reading previous comments is only 88 and up that do work (but I might be wrong)

@josefschabasser, thanks for checking. Does that browser allow you to do screensharing? reading previous comments is only 88 and up that do work (but I might be wrong)

As I posted yesterday: yes. I took the useragent string from my browser with which screen sharing works.

I missed that. Apologies

just to test it today, i'm glad the audio mic is works, but when i share my screen for other audience, they told me that they only see black screen, its really frustrating because with the officials ms teams from Windows, i can't to my microphone to working.

here is my pipewire output:

teams-for-linux --enable-webrtc-pipewire-capturer configPath = /home/pratama/.config/teams-for-linux Failed to get the config file, using default values configFile = {} processArgs [ '/opt/teams-for-linux/teams-for-linux', '--enable-webrtc-pipewire-capturer' ] did-finish-load did-finish-load [15459:0122/165858.370665:ERROR:adm_helpers.cc(73)] Failed to query stereo recording. [OpenH264] this = 0x0x21cf7604b930, Warning:ParamValidation(), AdaptiveQuant(1) is not supported yet for screen content, auto turned off [OpenH264] this = 0x0x21cf7604b930, Warning:ParamValidation(), BackgroundDetection(1) is not supported yet for screen content, auto turned off [OpenH264] this = 0x0x21cf7604b930, Warning:bEnableFrameSkip = 0,bitrate can't be controlled for RC_QUALITY_MODE,RC_BITRATE_MODE and RC_TIMESTAMP_MODE without enabling skip frame. [OpenH264] this = 0x0x21cf7604b930, Warning:Change QP Range from(0,51) to (26,35) window close

@josefschabasser, thanks for checking. Does that browser allow you to do screensharing? reading previous comments is only 88 and up that do work (but I might be wrong)

I normally use Firefox, so I've got Version 85.0.4183.121 (Official Build) (64-bit), and screen sharing works for me through the browser. It does not work for Firefox.

@josefschabasser Great discovery, screen sharing seems to work for me with Chromium as well!

Is there a workaround to this problem? I am also affected by it.
It works fine here on chromium browser 87.0.4280.88 (Developer Build) (64-bit) but not in this electron app.

Hi all, I think I got the solution... testing it in a virtual machine so it might not work but, hey, I thought to give it a try... branch is fix-406-screensharing-stopped-working. If any of you can prove it works, I will then release tomorrow.

The proposed solution comes form looking into their documentation (browser support). I tested things around and seems to work fine, but again, I am in a virtual machine so it might not hold true. (didn't work in the virtual machine without that change so I am hopeful)
image

Added "help wanted" as I need help to test it. Thanks an apologies I couldn't fix it earlier... ain't got time and work has give me a Mac, what difficult this sort of work a wee bit.

And alternative to test this is to run the client with the following user agent (argument):

teams-for-linux --chromeUserAgent "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3202.75 Safari/537.36"

Same user agent as in the change. In some cases you might need to clean your cache. If you loose your history, just clear the cache and you will get it back. Info in https://github.com/IsmaelMartinez/teams-for-linux/blob/develop/KNOWN_ISSUES.md#no-history

Hope helps.

IsmaelMartinez notifications@github.com writes:

And alternative to test this is to run the client with the following user agent (argument):

teams-for-linux --chromeUserAgent "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3202.75 Safari/537.36"

Same user agent as in the change. In some cases you might need to clean your cache. If you loose your history, just clear the cache and you will get it back. Info in https://github.com/IsmaelMartinez/teams-for-linux/blob/develop/KNOWN_ISSUES.md#no-history

Setting the user agent worked for me, both with a flatpak stable that
calls itself 1.0.0 and with 1.0.2 installed from a .deb

Thanks for doing that research!

d

Hi all, I think I got the solution... testing it in a virtual machine so it might not work but, hey, I thought to give it a try... branch is fix-406-screensharing-stopped-working. If any of you can prove it works, I will then release tomorrow.

Compiled and tested. Window and full desktop sharing works great on my Ubuntu 20.10.

Thanks !!

I then start the release process. I got a busy day/weekend and I haven't release for a while so it might take me a wee bit... just bear with me.

--chromeUserAgent "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3202.75 Safari/537.36"

worked for me. Thanks a lot!

Looking forward to the new release.

released now. https://github.com/IsmaelMartinez/teams-for-linux/releases/tag/v1.0.6 it might take a few more minutes to reach snap edge... Just promoted to stable but might take a few days to reach you.

I think you can do a snap refresh if you want to get it just now.

.deb installed, works great. Thanks.

Had to delete .config/teams-for-linux/Partitions/teams-4-linux/Application Cache

Thanks a lot for the quick fix, with 1.0.6 from Snap screen sharing works again for me

is the new build working by default when sharing on Wayland or i need to do something else?

I just wanted to say, that v1.0.6 works again (didn't have to clear cache).

Does it implement the pipewire screensharing? I'm also getting a black screen with only my cursor visible while using Sway (wayland)

Hi @ErikReider. This change doesn't fix the pipewire issue. Check this comment for how to can work around it

https://github.com/IsmaelMartinez/teams-for-linux/issues/406#issuecomment-761760830

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tulanian picture tulanian  路  6Comments

wagnst picture wagnst  路  5Comments

jpiautinity picture jpiautinity  路  8Comments

ellepdesk picture ellepdesk  路  7Comments

Kalyan-M picture Kalyan-M  路  8Comments