In our case, we had set channelLastN to 4. So it only showed 4 video streams and connection status inactive for the rest.
Same to me! It happens on filmstrip mode. Anyone knows how can we fix this? @damencho @Boris_Grozev.
I’m using the same version of meet.jit.si!
Prosody(0.11.5,Linux)
JiCoFo(1.0.606,Linux)
Videobridge version: 2.1.245-g49823c49
Same here. It happens even in 2 person meeting (p2p disabled).
The same issue is happening on the latest stable Jibri with youtube.
any help with that?
Same issue here… i´m running jitsi over Vmware.
Connections goes inactive.
regards
nacho
I have the same problem…
We are currently running the versions below are getting random inactive. Seems like video comes back on when the “inactive” participant but not always. The tiling on "inactive " participant goes to a dim grap with a white icon.
jicofo /stable 1.0-644-1 all [upgradable from: 1.0-589-1]
jitsi -archive-keyring/stable 1.0.1 all
jitsi -meet/stable 2.0.5142-1 all [upgradable from: 2.0.4627-1]
jitsi -meet-prosody/stable 1.0.4466-1 all [upgradable from: 1.0.4127-1]
jitsi -meet-tokens/stable 1.0.4466-1 all
jitsi -meet-turnserver/stable 1.0.4466-1 all [upgradable from: 1.0.4127-1]
jitsi -meet-web/stable 1.0.4466-1 all [upgradable from: 1.0.4127-1]
jitsi -meet-web-config/stable 1.0.4466-1 all [upgradable from: 1.0.4127-1]
jitsi -upload-integrations/stable 0.15.15-1 all
jitsi -videobridge/stable 1126-1 amd64
jitsi -videobridge2/stable 2.1-376-g9f12bfe2-1 all [upgradable from: 2.1-202-g5f9377b9-1]
Would disabling layer suppression fix this?
Same problem in multi-party meetings. Rolling blackouts. Any help from the developers would be appreciated.
We have disableSimulcast: true in config.js file. Would this cause the “Inactive” issue?
We have the same issue after update to jitsi-videobridge2=2.1-376-g9f12bfe2-1 and lib-jitsi-meet#f370cccdfba6f9190ecb4afc3d78552d9f3ad57c. channelLastN is set to -1. The connection status can be set to “inactive” for a few seconds for random participants, and then it becomes “good” again. For these users I see the logs “Detector track RTC muted”.
2 Likes
It seems this is to do with congestion control on the Jitsi video bridge.
Is there any update on this?
Please. Is there any way to stop this happening. We’ve put in a TON of work on this project to record multiple guests and at the moment there’s a huge risk it’s all been a total waste of time if guests go inactive during a live stream or recording!
Does this happen with the latest stable release 2.0.5390? This thread is rather old and you do not provide any information regarding your setup/configuration.
If you are absolutely certain that sender and receiver bandwidth is sufficient and receiver processing power is sufficient and you think the issue lies in bandwidth estimation or allocation, you could try to disable bandwidth estimation. That is, disable TCC and REMB in config.js and perhaps even set trust-bwe=false in your videobridge config. This may, of course, come with other uninteded side-effects…
Sorry, for some reason I didn’t get a notification to this reply.
I’m on a developer version from github. The same version I cloned some weeks ago. I’ve just pulled the latest today though. Also trying your suggestions. Too soon to say if the problem has gone.
All my tests have been over the local network but both that and my internet are 1Gb. With a maximum of 4 clients and the server running on a dedicated mini pc running Ubuntu (not the biggest spec but a Intel Celeron J4125 Quad Core and 8GB of RAM so should be fine for 4 HD streams surely?!).
I am having the exact same problem for a couple of weeks now. I just use jitsi meet on various platforms and this happens almost on every call now. However, I have noticed that this does not happen on all networks I connect to, although the networks that have the problem are quite fast bandwidthwise. This doesn’t happen on any other conferencing platform, it is jitsi-meet specific for some reason. This is so frustrating. Is there any way to see why the connection switches to inactive?
We are using Jaas service and facing same issue. It happens when third user connects to the room (and jitsi is switching to bridge). We loose connections to all other participants for few seconds (they have inactive state), than it is recovered. Anyone can help with it, @damencho?