The issue that prevents users from starting streams while watching another stream persists.

[Tecnio]

Describe the bug
When a user is attempting to start a screen share while watching someone else's screen share, the stream will get stuck in a loading loop. This issue was apparantly fixed by kaitlynkittyy's merge requests however still persists after updating to 1.5.2.

To Reproduce

1. Join a voice channel in a server.
2. Watch another users stream by clicking "Watch Stream".
3. Attempt to start a screen share at any setting.

Expected behavior
The stream to successfully start instead of getting stuck loading.

Screenshots

Desktop (please complete the following information):

• OS/Distro: Fedora Linux
• Version: 40
• Desktop Environment (linux only): GNOME

Command line output

[67460:0501/211440.939755:ERROR:screencast_portal.cc(367)] Failed to start the screen cast session.
[67460:0501/211440.939771:ERROR:base_capturer_pipewire.cc(81)] ScreenCastPortal failed: 2
Error during screenshare picker Failed to get sources.
(node:67460) UnhandledPromiseRejectionWarning: TypeError: Video was requested, but no video stream was provided
    at AsyncFunction.<anonymous> (VCDMain:24:2158)
(Use `vesktop --trace-warnings ...` to show where the warning was created)
(node:67460) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 4)
[67521:0501/211444.289233:ERROR:vaapi_video_decoder.cc(1242)] failed Initialize()ing the frame pool
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:426 pw_thread_loop_wait()
[2024-05-01 21:14:48.337] [venmic] [info] [patchbay] (get) running venmic 3.4.2
[2024-05-01 21:14:48.340] [venmic] [info] [patchbay] (handle) found default metadata: 37
[2024-05-01 21:14:48.340] [venmic] [info] [patchbay] (meta_update) speaker name: "alsa_output.pci-0000_2d_00.4.analog-stereo"
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:426 pw_thread_loop_wait()

Additional context

The issue seems to be happening with other friends using Vesktop.

[PolisanTheEasyNick]

That's Discord's bug which is reproducible even in Windows Web to Windows Web streaming, so we can't do anything about it.
While debugging, I found out that while watching another stream and creating new stream, the MediaStream is not assigns in conn.input so without fixes from Discord's side we can't do anything.
Here is created connection for stream without MediaStreams objects at .input.desktop and .input.stream:

And here is how it should look:

I already reported that to Discord Support but I do not believe that they will do something about it.
As temporary workaround you should manually rechange window after starting stream.

[S3nsh1r0]

I have a similar problem. If any other one on a call has the video streaming on simultaneously with me and then turns his of then mine is also stuck in a loading loop. Just thought of commenting that if that could be helpful/fixed (when it`s not a Discord sided bug). All in all, it is just very annoying :p

[catgirlcataclysm]

That's Discord's bug which is reproducible even in Windows Web to Windows Web streaming, so we can't do anything about it. While debugging, I found out that while watching another stream and creating new stream, the MediaStream is not assigns in conn.input so without fixes from Discord's side we can't do anything. Here is created connection for stream without MediaStreams objects at .input.desktop and .input.stream: And here is how it should look: I already reported that to Discord Support but I do not believe that they will do something about it. As temporary workaround you should manually rechange window after starting stream.

maybe until then, we could add a workaround that checks if a stream exists from another user, and automagically applies the stream twice to bypass the issue?

[S3nsh1r0]

If that is not too complicated to do, then yeah. is it then good to push it as an Dev. setting in Vencord?

[catgirlcataclysm]

If that is not too complicated to do, then yeah. is it then good to push it as an Dev. setting in Vencord?

Ill test with the workaround if I have time later today, and if it works ill just PR it as default behavior until discord fixes it

[PolisanTheEasyNick]

maybe until then, we could add a workaround that checks if a stream exists from another user, and automagically applies the stream twice to bypass the issue?

I tried with no success.

1. it will require another call to system's portal for getting new MediaStream (using native WebRTC API, not electron's one)
2. Even with this while setting this MediaStream to connection, connection just dies and stream dies at all.

Need more tries tho, but I do not think that we must create another calls to portal for upstream discord bug.
I think changing window manually or stopping watching another stream will be more comfortable compared to one more time picking screen.

[catgirlcataclysm]

maybe until then, we could add a workaround that checks if a stream exists from another user, and automagically applies the stream twice to bypass the issue?

I tried with no success.

1. it will require another call to system's portal for getting new MediaStream (using native WebRTC API, not electron's one)

2. Even with this while setting this MediaStream to connection, connection just dies and stream dies at all.

Need more tries tho, but I do not think that we must create another calls to portal for upstream issue bug.

ahh, interesting. I'll try some stuff later too, but I doubt I'll find much that's new

[pixL404]

Hi, what is the current status of this issue?

Screen sharing is not working for me on NixOS (Wayland Session) with the version 1.5.2

[Tecnio]

Issue is resolved.

[alothings]

@Tecnio how was the issue resolved? I have the same issue.

Fedora/XFCE
Issue: During a group call on the Study Together channel, I can't focus on some cameras, sometimes. It is very random. It seems to be when the groups are large (15+ people). When there is only 4 people streaming their cameras, I have no issues focusing on someone.

[Tecnio]

It was fixed in a Vesktop update and I haven't had this issue ever since. However there still seems to be a similar (albeit different) issue where some screenshares get stuck on the loading and randomly not load but I have no information, nor know the cause so I can't exactly open a bug report about it. Your issue is probably not related to this as it had no relation to the count of people on the call.