Meet.jit.si app: meeting participants end up in two separate meetings?

I had a meet.jit.si meeting just now with a total of 7 participants. Unfortunately, it seems we ended up in two separate meetings: one with three people, and one with four. All of us were using the exact same URL.

Any way to fix this?

Thanks!
Bart

This happened to me (and the organisations I am in) quite often and on many different server instances. This makes Jitsi pretty much useless for us.

It seems that this “split brain” happens mainly when a user leaves.

Are you seeing this on meet.jit.si?

I have not tried it lately, but half a year ago it was a problem for sure on meet.jit.si.

Also, I have had this exact issue on https://open.meet.switch.ch/, https://meet.immerda.ch/ (both not my instances) and on a custom installation.

I’m not aware of those deployments and how they are configured, I can speak only for meet.jit.si, that we detect such problems and fix them. And we are working on eliminating or minimising them.

@rettichschnidi & @damencho We (SWITCH, https://switch.ch) have deployed https://open.meet.switch.ch (and others). I am working on a write up (we have 22 jitsi-meet instances sharing 32 videobridges, running the nightly version) of our setup (with Ansible playbooks to install it, but I need to sanitize the repository before releasing it).

I have also seen and heard about the split brain instances. If we can help debugging that, we’d gladly assist.

How do you stick sessions?

Do you mean web browser sessions @damencho? Every instance currently only uses on web server, so the sessions are handled by that specific nginx/meet/jicofo stack.

I assume that Jicofo schedules new particpants to a specific conference to the same video bridge the others already are using… I looked through the forum and haven’t seen any other relevant note of session stickyness (except [jitsi-dev] Jicofo SPoF which I think doesn’t apply to our setup)

How do you stick a browser session to the desired instance of nginx?

We have 22 instances of nginx running - each on its own host/domain name (open.meet.switch.ch, foo.meet.switch.ch, bar.meet.switch.ch etc). Users usually only use one of these instances and open their conferences on there. As far as I can see, we don’t need any additional session stickiness.

Basically we run 22 shards (that look like individual Jitsi installations) that share the same set of videobridges.

I see, so people to land in different rooms(different shards) … the only option is to send them different links …

That is not the problem. People using the same link (open.meet.switch.ch/foo) land in different rooms

I cannot understand then the architecture. This means using the same link they end up on different shards, different prosodies and open the same room name and they do not see each other. So there must be something on the way that forwards them in different muc rooms.
They cannot open the same room name on the same prosody server and do not see each other, they will see the thumbnails of the other person at least.

What I have heard from people in those split conferences was that they could see the same chat, but they were separated into 2 disjunct groups of videos. That would mean, that they are on the same prosody server, but somehow not on the same bridge?

We have updated the whole stack to the nightly release from yesterday and I will see if we still have this problem.

That sounds very strange … and audio was fine? This sounds like bwe (bandwidth estimation) where some people were getting one set of videos and the other another set of videos … due to bandwidth. Are there ninja icons on the thumbnails they do not see?

In fact, I do not know if it is a chronic problem or not, but in the infrastructure we set up about distance education, when students move from one lesson to another, sometimes they cannot meet with the teacher and although they click the same room, 3-4 students stay in one room, and another room with the teacher and several students. By logout login from the backend, they can meet in the same room. Whether this is related to the browser’s cashe problem, is it a jitsi-related problem, we have not yet identified… (We have just one shard, 1 jitsi-meet and a few jvbs)

Are you seeing the thumbnails and you don’t see the video in them, and also audio is not heard. Or the thumbnails for the other participants are missing?

No, thumbnails are missing, they are in another room

It is the first time I hear about such problem when running just one xmpp server (one shard). If you can extract js console logs from the browser from two different sessions that do not see each other at the same time, this will be interesting. Also collecting prosody logs at the same time.

Were there any updates on this issue? I just got an email forwarded, from someone using meet.jit.si and experienced the problem (in april 2020), that for a number of users the ongoing session disconnected and afterwards they found themselves separated from the rest of the group, although the URL looked still the same. So somehow it doesn’t look like a deployment problem.