[BUG] Streaming/Webcam stops working if you change the quality after already streaming once

[sivert-io]

Component

Client (Desktop / Electron)

What happened?

Seems to be related to some clean up missing. When you start a stream after doing Ctrl + R or launching the app, everything works fine. However if you stop the stream, change the quality and start it, participants can no longer see your stream.

Steps to reproduce

1. Launch gryt chat
2. Join a voice channel
3. start streaming in e.g. native 60 fps
4. stop streaming
5. start again, but this time set resolution to 1080p 60 fps

Expected behavior

Stream should start no matter what.

Environment

• OS: Windows 11
• Gryt version: 1.0.124
• Deployment: Docker and gryt.chat
• Self-hosted: yes

Logs / error output

Screenshots

No response

[sivert-io]

I'm working on releasing a new method for capturing desktop and windows on Windows machines. For now this issue will probably prevail.

[tecke1]

I'm working on releasing a new method for capturing desktop and windows on Windows machines. For now this issue will probably prevail.

it will be great if screen sharing performance will at the discord level, cause now, gryt consumes a lot of pc resources in comparison, and screen sharing eats up a lot of cpu

also it would be super to add rnnoise settings because me and my friends often have extra noise or voices captured and become robotic

[sivert-io]

@tecke1 Indeed it does 😄 Due to being limited to VP9 encoding only (CPU encoding only). Will hopefully soon release the update that enables GPU encoding and all the other codecs supported by WebRTC 🙂

[ovprc]

it's not related to stream settings

it also happens if:
there was multiple streams and one of them even just turns off. it will break every other stream tiles and spams in console

VoiceParticipantCard screen tile: found=false

can be fixed only for user that rejoins voice chat and starts stream again. every other streams remain broken until any other users that was also streaming rejoin vc

OR

if I restart stream without changing anything. it has some chance to broke my stream if I was streaming already for some time and decided to restart it.
fixes the same way. disconnect and connect to voice chat and start stream again

Client:
Standalone
Windows 11 Pro 25H2 26200.8037
tested in v1.1.4 and pre-release v1.1.24
bug remains in both versions

Server:
docker-compose
self-hosted
v1.0.66

[sivert-io]

@ovprc Thanks a lot for the added details!

I'm pretty sure I covered this in the latest beta release, but I'll have to do some extended testing just to be sure 😄

If you're interested in testing this in the latest beta (no pressure, it requires a bit of setup), you can toggle the beta channel in Settings -> About -> Beta toggle. The server-image will also have to be set to use beta channel if you wish to test it properly.

Example beta-compose is here: https://raw.githubusercontent.com/Gryt-chat/gryt/main/ops/deploy/compose/beta.yml

[defectly]

@ovprc Thanks a lot for the added details!

I'm pretty sure I covered this in the latest beta release, but I'll have to do some extended testing just to be sure 😄

If you're interested in testing this in the latest beta (no pressure, it requires a bit of setup), you can toggle the beta channel in Settings -> About -> Beta toggle. The server-image will also have to be set to use beta channel if you wish to test it properly.

Example beta-compose is here: https://raw.githubusercontent.com/Gryt-chat/gryt/main/ops/deploy/compose/beta.yml

This happened when i toggled release/beta in windows desktop app.
Also my mouse became super laggy and system started beeping.. But when i pressed ok in this error message, update installed successfully.
Also, video streams only in h264, vp9 and av1 doesn't appear in debug

[ovprc]

@ovprc Thanks a lot for the added details!

I'm pretty sure I covered this in the latest beta release, but I'll have to do some extended testing just to be sure 😄

If you're interested in testing this in the latest beta (no pressure, it requires a bit of setup), you can toggle the beta channel in Settings -> About -> Beta toggle. The server-image will also have to be set to use beta channel if you wish to test it properly.

Example beta-compose is here: https://raw.githubusercontent.com/Gryt-chat/gryt/main/ops/deploy/compose/beta.yml

The bug is still present.

Server v1.0.73
SFU v1.0.45

Both users are using the client:
standalone Gryt v1.1.24

Steps to reproduce:

1. Both users started screen sharing.

• Both users could see two screen shares.

2. I restarted my screen share twice without changing anything.

• On my side, I could still see both screen shares at the same time.
• My friend stopped seeing my screen share but could still see their own.

3. I opened the expanded view of my friend's screen share and then minimized it back.

• I stopped seeing all screen shares.
• My friend still saw only their own screen share, since they didn’t interact with the UI.

4. Restarting any of the screen shares caused the streams to disappear for both users. Only a small blue screen share icon is shown.

• Both users cannot see any screen shares until they reconnect to voice chat and start screen sharing again.

The only change in the console logs:

[ScreenShare] VoiceParticipantCard screen tile: nick= streamID= found=false videoStreamKeys=[]

(I don't know about leaving nickname or any of id's. I removed them from here, but they exist)

found=true -> found=false

found=true - everything works
found=false - screen shares are not displayed

[ovprc]

This happened when i toggled release/beta in windows desktop app. Also my mouse became super laggy and system started beeping

I think this is not the right issue to discuss this specific problem

I didn’t experience this behavior when switching to the beta and back, so you might want to take a closer look at your OS or hardware

[sivert-io]

@defectly @ovprc Thanks a ton for the insight!!

It might just be that i'll mark screen sharing as experimental and continue working on it in the background. It's probably gonna take a few weeks until I can make it stable.

@defectly Regarding the application error, It's a bit difficult to replicate as it depends on many factors such as OS version, drivers installed, and so on... However I will keep an eye out for any future issues related to it.

I really appreciate your comments, they're very valuable! 😄

[sivert-io]

I might have cracked the case on this. It seems to be related to StreamID not being assigned to a peer. We'd probably just need to move the assign-time in the receive stream flow, alternatively just retry if it's undefined