Desktop client does not re-subscribe to existing publisher after switching from browser to desktop (no audio from other user)
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.
Description
When switching a user session from browser to the Talk desktop client, the desktop client fails to re-subscribe to some existing publishers. As a result, the user cannot hear an other participant, although other participant's publishing still works. The other participant can hear and subscribe to the user switching from browser to desktop app.
Timeline (I made this summary after analysing signaling logs with a script)
20:02:48 — user1 registered in browser with session X.
20:38:40 — user2 registered in desktop app with session Y.
20:38:55 — user1 (browser) subscribed to user2 with handle 3640009136193936. Audio worked.
20:44:27 — user1 registered in desktop app with session Z.
20:44:32 — Handle 3640009136193936 and other related user1's browser session handles were freed including the handle 3640009136193936 of subscription to user2's video:
2025-08-13T20:44:32.968855+02:00 signaling janus[3398684]: [3640009136193936] WebRTC resources freed
2025-08-13T20:44:32.968919+02:00 signaling janus[3398684]: [3640009136193936] Handle and related resources freed
After this, user1 re-subscribed to other users's video, but never re-subscribed to user2's video.
Later at 21:28:59 and 21:32:41, user1 and others subscribed to user2’s screen share successfully — but user1 never got audio from user2 anymore.
Expected behavior
When the user switches from browser to desktop client, the desktop app should automatically subscribe to all currently active publishers in the room, including audio streams from existing participants.
Actual behaviour
The Talk desktop app fails to re-subscribe to some publishers (in this case, user2).
Environment
user 1: Agent when using browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36
Agent when using Talk desktop: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) NextcloudTalk/1.2.5 Chrome/138.0.7204.100 Electron/37.2.3 Safari/537.36
user 2: Agent when using Talk desktop: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) NextcloudTalk/1.2.5 Chrome/138.0.7204.100 Electron/37.2.3 Safari/537.36
User's 2 Diagnosis report
### Diagnosis report| Nextcloud Talk Desktop | |
|---|---|
| Version | v1.2.5 |
| Built-in Talk version | v21.1.2 |
| Release channel | stable |
| Operating system | Windows_NT 10.0.19045 (Windows 10 Pro) |
| Executable Path | H:\PartageLCTQ04\NextcloudTalk\app-1.2.5\Nextcloud Talk.exe |
| Connected to | - |
| Nextcloud version | 31.0.7 |
| Nextcloud Talk version | 21.1.3 |
notifications app enabled |
✅ yes |
notify_push app enabled |
❌ no |
Application config
{
"launchAtStartup": false,
"theme": "default",
"systemTitleBar": false,
"monochromeTrayIcon": false,
"zoomFactor": 1,
"playSoundChat": "respect-dnd",
"playSoundCall": "respect-dnd",
"enableCallbox": "respect-dnd",
"secondarySpeaker": false,
"secondarySpeakerDevice": null,
"trustedFingerprints": []
}