Issue: Freezing cams in the Foundry Client and Chrome

[Chainsoroth]

I am using the standard configured jitsi server.
When I am using the Foundry client or Chrome, only two cameras stay active the other (mostly three due to there being four players and the gm) get frozen after a few seconds.
When I use Firefox (my unpreferred browser) all cams work fine.

[bekriebel]

@Chainsoroth What do you mean by the standard configured Jitsi server? Do you mean the "Public Jitsi Meet Beta" server, or one that you configured?

I have seen video freeze from time to time when there is no audio. I think Jitsi or Chrome may be trying to optimize the bandwidth usage by not sending streams to those who are muted. If users begin talking, does their video come back?

[Chainsoroth]

Yep, I mean the "Public Jitsi Meet Beta" Server.
I configured the broadcast to be video only because we use discord for voice.
I will try to test it with activated voice the next time we play to try and find out if it's because of the deactivated voice.
Is it possible to deactivate that mentioned bandwidth opimization?

[bekriebel]

Ahh... That's a good tip. I'll try testing with that soon and see if I can reproduce it. There may be some special config value I can pass to jitsi to make it stop freezing the video when there is no audio being recieved. It's possible they don't allow that to be bypassed on their servers, though.

[Chainsoroth]

Testet it yesterday with the settings on broadcast video/audio activated and everybody on push2talk (still talked through discord). The cams still froze up in Chrome/Foundry Client.

[bekriebel]

I'm having a hard time reproducing this issue. A few more questions:

1. Are all users on Chrome? Latest version?
2. What OS/OSes are being used by you and the other users?
3. When someone's video freezes, does it freeze for everyone? Is everyone experiencing freezing?
4. Is your machine or the users' machines lagging in other ways? I was able to get video to freeze, but only by having the sender or receiver's CPU overloaded.
5. Anything else specific that you can think of?

[Chainsoroth]

If you are active in the Foundry Discord, hit me up (Chainsoroth) there, maybe we can look into it together/on the same server?
To answer your questions:

• Some Chrome, some Firefox (we tried to switch all from one to another, made no difference for the cams)
• 4/5 on Win10, one on Win7
• No, not everyone is experiencing freezing. It is only for the affected person it seems
• Nah, no lagging machines here. We all have quite potent gaming rigs.

[bekriebel]

I'm on the Foundry Discord server as bekit#4213. I'll hit you up later this week when I'll hopefully have some more time to look into it.

[bekriebel]

FYI, I may have finally made some progress on this last night. I have some additional logging in place and I think I see where the freezing is happening. I just need to recreate it a couple of more times so I can track down what is actually causing it. I think it's Jitsi attempting to optimize streams to reduce bandwidth for users who aren't sending audio.

[bekriebel]

Noting to myself there there may be relation to this issue: jitsi/jitsi-videobridge#777

[Chainsoroth]

Brilliant news! We switched to Discord Video for the time being, as I said earlier, If you need help in testing / forcing the issue just hit me up on discord.

[bekriebel]

@Chainsoroth can you give v0.4.17 a try? After testing, I made several adjustments to hopefully address this.

One thing I noticed is that I'm having occational issues with FireFox clients when using the default beta.meet.jit.si server. However, I am getting the same types of issues when using the main Jitsi Meet page using that server and I'm not getting the issues when using my own test server or the production meet.jit.si server. I think they might have a bug in the video bridge component running on the beta server. I also haven't seen the error with Chrome based clients.

[Chainsoroth]

Issue still persists, tested it with my group this Thursday.

[bekriebel]

Hrmm... I tested this last week with two groups. One of them previously had a lot of freezing issues. The only issue I had was one user on Firefox wasn't visible when he first joined. We waited while others were joining and after a couple of minutes his video appeared. From the logs, I could see that Jitsi saw the video as interrupted, likely due to Firefox's webrtc implementation.

Other than that, both sessions were rock solid. We play with audio and video, but there were plenty of times where users were muted or using push-to-talk.

@Chainsoroth can you confirm that all users are using Chrome, or were some users on Firefox? Do you know how much bandwidth is available to each user? The settings should make the bandwidth requirements quite low, but Jitsi will still auto-adjust based on bandwidth estimates to the server. It will lower quality & framerate first, but eventually will cut video off in either sending or receiving if it things there is too little bandwidth available.

Another test that could be run is to connect with the same users to a standard meeting on beta.meet.jit.si (your your own server if you are using one). Have everyone go into gallery view and use/don't use audio in the same way you have been with FVTT. If freezing also happens there, then it is being caused by Jitsi's connection algorithms and I'm afraid there's not much else I can do.

I'll try checking on Discord to see if anyone else is still experiencing these issues.

[MrWook]

We just had this issue in our group.
We had played a few rounds with 4 players all of them used chrome. At a new session our fifth player finally bought a camera and used Firefox. At this point on we got constant freezings and the videos were removed/kicked from the jitsi server or what ever.
I found this issue here and the linked jitsi-videobridge issue and told the fifth player that he should switch to chrome.
It immediately remvoed the video problems and everything worked fine again after everyone had used chrome.

We are using the default jitsi config. So we are using the "Public Jitsi Meet Beta" Server.

[bekriebel]

Unfortunately, it seems like Jitsi and Firefox don't get along very well. There are a lot of FF bugs related to Jitsi.

One thing you could try is to switch to "Custom Server" and set the signaling server URL to meet.jit.si. No username or password is needed. This will use the "stable" jitsi meet servers, which may work better than the current beta.

If that works well, let me know. I may just have to update the documentation to recommend chromium based browsers.

[bekriebel]

I would also recommend making sure that they are using the latest version of Firefox. It looks like a significant bug was fixed within the last couple of months: https://bugzilla.mozilla.org/show_bug.cgi?id=1668028

[mikkerlo]

Hi! Any updates on this? All of my team using chrome, and we also have these weird issues. Script await game.webrtc.connect() helps with the issue, but it causes reshuffling on the external foundry page. I am ready to give you any logs or other help that you want to prevent these issues, seeing all players on the foundry page to awesome for me to change this.

[bekriebel]

Not really any update, no. I have been unavailable to work on this for the last month or so and also haven't run any games in that time either. I'm running a game this evening so I'll see how that goes. It may just be that we are hitting issues with Jitsi itself. @mikkerlo are you using the default public server, or one of your own? It seems like connections to the public server are hit or miss since it isn't considered a production server, just a demo server.

[mikkerlo]

@mikkerlo are you using the default public server, or one of your own? It seems like connections to the public server are hit or miss since it isn't considered a production server, just a demo server.

I am using my own server, and if we use Jitsi in Chrome that everything works ok.

[bekriebel]

Unfortunately, issues like this seem to be pretty common with Jitsi, especially if trying to use FireFox clients. I highly recommend checking out a new module that I just published: https://foundryvtt.com/packages/avclient-livekit - This uses LiveKit instead of Jitsi for the A/V platform. It has been significantly more stable and reliable for me during my testing.