Inconsistent Muted State
Open
Nobody has claimed this yet.
bug
- Dominant language
- JavaScript
- Stars
- 2.2k
- Forks
- 586
- Avg merge
- 18h 27m
- Merged PRs (30d)
- 333
Description
How to use GitHub
- Please use the π reaction to show that you are affected by the same issue.
- Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
- Subscribe to receive notifications on status change and new comments.
Steps to reproduce
- Start a call with multiple users.
- Leave call, reconnect.
- Might occur for multiple users.
Expected behaviour
User mute state is consistent between clients.
Actual behaviour
In this specific case, I joined a group call with about 5 users, 2 users are "muted" for me, but the other 2 users can hear them, leaving and rejoining does fix, as well as restarting the client. These "muted" users are not actually muted, but my client is treating them as muted.
Diagnosis and logs
Diagnosis report
### Diagnosis report| APPLICATION | βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ |
|---|---|
| Version | v2.1.1 |
| Built-in Talk version | v23.0.1 |
| Release channel | stable |
| SYSTEM | βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ |
| Operating system | Linux 6.19.6-2-cachyos (#1 SMP PREEMPT_DYNAMIC Fri, 06 Mar 2026 11:29:20 +0000) |
| Executable path | /app/lib/com.nextcloud.talk/Nextcloud Talk |
| Using Wayland | β yes |
| SERVER | βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ |
| Server version | v33.0.0 |
talk app |
v23.0.2 |
notifications app |
β Enabled |
notify_push app |
β Enabled |
Application config
{
"launchAtStartup": false,
"theme": "dark",
"systemTitleBar": true,
"monochromeTrayIcon": false,
"zoomFactor": 1,
"playSoundChat": "respect-dnd",
"playSoundCall": "respect-dnd",
"enableCallbox": "respect-dnd",
"secondarySpeaker": false,
"secondarySpeakerDevice": null,
"lastAppVersion": "2.1.1"
}
Client logs
index.js:24 Using locale "en_US" for language "en"
6035.js?v=3c721e6ebed9a2107c71:11 Not connected to signaling server yet, defer joining room 6y8ejazz
vision_wasm_internal.js:3401 I0322 23:21:04.239000 2225904 gl_context.cc:407] GL version: 3.0 (OpenGL ES 3.0 (WebGL 2.0 (OpenGL ES 3.0 Chromium))), renderer: WebKit WebGL
vision_wasm_internal.js:5938 W0322 23:21:04.243000 2225904 gl_context.cc:1118] OpenGL error checking is disabled
custom_dbg2 @ vision_wasm_internal.js:5938
vision_wasm_internal.js:939 Graph successfully started running.
6035.js?v=3c721e6ebed9a2107c71:226 Joining call
vision_wasm_internal.js:3401 I0322 23:21:05.868999 2225904 segmentation_postprocessor_gl.cc:446] NONE activation function chosen on GPU
vision_wasm_internal.js:939 Graph finished closing successfully.
vision_wasm_internal.js:3401 I0322 23:21:06.279000 2225904 gl_context_webgl.cc:140] Successfully destroyed WebGL context with handle 1
vision_wasm_internal.js:3401 I0322 23:21:07.369999 2225904 gl_context.cc:407] GL version: 3.0 (OpenGL ES 3.0 (WebGL 2.0 (OpenGL ES 3.0 Chromium))), renderer: WebKit WebGL
vision_wasm_internal.js:5938 W0322 23:21:07.388000 2225904 gl_context.cc:1118] OpenGL error checking is disabled
custom_dbg2 @ vision_wasm_internal.js:5938
vision_wasm_internal.js:939 Graph successfully started running.
6035.js?v=3c721e6ebed9a2107c71:208 localMediaStarted
vision_wasm_internal.js:3401 I0322 23:21:10.023000 2225904 gl_context.cc:407] GL version: 3.0 (OpenGL ES 3.0 (WebGL 2.0 (OpenGL ES 3.0 Chromium))), renderer: WebKit WebGL
vision_wasm_internal.js:5938 W0322 23:21:10.039000 2225904 gl_context.cc:1118] OpenGL error checking is disabled
custom_dbg2 @ vision_wasm_internal.js:5938
vision_wasm_internal.js:939 Graph successfully started running.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up β it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the group-call sequence: join with multiple users, leave, reconnect, and compare each client's mute state with what others hear. Review the client logs around signaling, joining, and local media startup; done means remote users' displayed mute states stay consistent after reconnecting.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- audio-video-rtc
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100