talk-desktop icon indicating copy to clipboard operation
talk-desktop copied to clipboard

Desktop client does not re-subscribe to existing publisher after switching from browser to desktop (no audio from other user)

Open AssiaAzzouzi opened this issue 4 months ago • 0 comments

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": []
}

AssiaAzzouzi avatar Aug 19 '25 08:08 AssiaAzzouzi