[Bug]: Camera turns off mid call

[GodsBadAssBlade]

Can you reproduce this bug on the Microsoft Teams web app (https://teams.microsoft.com)?

No

Describe the bug

the camera turns off mid call at random and cannot be turned back on

What package are you using?

flatpak

Version

2.8.0

Reproduction steps

1. start the app
2. join a video call
3. after an undefined time camera turns off and refuses to boot back up in app

Expected Behavior

1. start app
2. join a video call
3. the call is uninterrupted by camera issues due to the software

Debug

unfortunately I cannot provide as I didn't have it running during the meeting and I use the app very infrequently

Additional context

To make sure this is clear, the camera itself is perfectly fine, other apps were able to use it no problem even during the call(AFTER the bug was made present, to confirm it was the app itself having issues). It's a NEXIGO HD webcam

[github-actions]

Simili Triage Report

Note

Quality Score: 8.5/10 (Good)
The issue could be improved. See suggestions below.

Classification

Category	Value
Labels

Quality Improvements

• Missing error logs or debug output
• Operating system and version not specified
• Provide any relevant error messages or logs from the application or system when the camera turns off
• Specify the operating system (e.g., Ubuntu, Fedora) and its version

Similar Threads

Similarity	Type	Thread	Status
84%	📝	#883 Camera does not work unless restarting teams	Closed
82%	📝	#982 USB camera lost during call	Closed
80%	📝	#2169 [Bug]: Cam broken during meetings	Closed
80%	📝	#1567 [Bug]: camera sharing not working	Closed
80%	📝	#1567 [Bug]: camera sharing not working	Closed

Warning

Possible Duplicate (Confidence: 90%)
This issue might be a duplicate of #982.
Reason: The current issue describes the camera turning off mid-call at random and being unable to be turned back on. Issue #982 describes the 'USB camera lost during call' or 'lost completely within a call'. Both issues detail the camera becoming completely unavailable during an active call, sharing identical symptoms and expected outcomes. The current issue's mention of 'flatpak' also aligns with comments in #982 regarding issues with sandboxed versions. A single fix addressing the camera dropping mid-call would resolve both issues completely.
Also related to: #883 (Camera does not work unless restarting teams), #2169 ([Bug]: Cam broken during meetings), #1567 ([Bug]: camera sharing not working)

⏳ This issue will be automatically closed in 72 hours if no objections are raised. If you believe this is not a duplicate, please leave a comment explaining why.

---

_{Generated by Simili Bot}

[IsmaelMartinez]

Thanks for the report. simili-bot's duplicate call on #982 is a pass, the symptom is similar but that ticket is from 2023 with a different root cause and was closed three years ago, so this is not the same thing; you can ignore the auto-close warning.

Without a log we cannot tell whether this is the camera itself being released by the sandbox, Teams's video pipeline hitting an error and not recovering, or a Chromium-side capture issue from the Electron bump in 2.8.0. The most useful next step would be a debug log from a session that actually triggers the drop. Next time you use the app, could you launch it like this (from a terminal, not the Flatpak launcher, so the logging flags land):

flatpak run --command=teams-for-linux com.github.IsmaelMartinez.teams_for_linux \
  --logConfig='{"transports":{"console":{"level":"debug"}}}' 2>&1 | tee /tmp/tfl.log

Then when the camera drops and will not come back, attach /tmp/tfl.log here.

Two more things worth trying in parallel, because both have a decent prior probability of being the cause:

1. Flatpak confinement is a common failure mode for camera handover, because camera access goes through xdg-desktop-portal and the portal does not always reacquire a stream cleanly after a drop. If you can, install the .deb from https://github.com/IsmaelMartinez/teams-for-linux/releases and retry. If the problem only happens on Flatpak, we have the answer without any further digging.
2. 2.8.0 bumped Electron from 39 to 41, and we have one other 2.8.0-era ticket ([Bug]: Can not see shared screen of remote user if I get called in a one-on-one session #2459) where a GPU or compositing regression is suspect. If installing 2.7.13 is painless on your side, retrying there would tell us whether this is a 2.8.0 regression on our side or something older.

Labelling flatpak, media, platform:linux, and awaiting user feedback while we wait for the log.

I hope helps!