Users do not see all streams or a limited number of streams but some do see all streams

Hello,

In “tile view” with around 15 users, some users see all users, and some users only a couple of users. The other users in this case appear as a “black” screen, but talking is always possible.

This question is about : How can we make it happen that everybody can see everybody? Looking at the network indicator of the different users, it looks like the network was ok and the cpu of the system was below 60%.

It can also happen that a user sees everyone and other users see many black video screens, and that when those users refresh, the user who previously was able to see everyone, suddenly sees only 3 participants and the others are “black”. This would be fine if, after some seconds, the “black” users would appear again, but this does not happen they stay “black”.

What could be the reason for this? Is there something we need to configure?

Regards,
Robert

Do you see an avatar for the users without video? And a small “ninja” icon on the top left of the tile?

Generally speaking, the JVB will ssend a particippant as many tiles as it thinks it can handle, based on the bandwidth estimation. Available bandwwidth, llossy networks, etc have an effect on this, so the fact that 1 participant in the meeting can see everyone doesn’t necessarily mean everyone else will get the same experience.

Browser console logs for the affected participants would help better understand the situation.

I don’t recall seeing the ninja avatar and just realized what that is so I will make sure to instruct everyone to lookout for it, thanks. So in your opinion this only has to do with the bandwidth of the client?

Because I do think it is strange if I see 14 participants, and 12 of those participants reload I see then only 3 and it stays that way, and that if I do a reload I suddenly see 12 participants again. So the reload helps, but then if other users reload, more black screens appear and I am seeing less and less streams.

Has anyone experienced this ?

Mostly, but also CPU overuse can be a factor. Clients will “push back” if their CPU is melting.

I think this can be explained by the “ramp up” period. In the beginning bandwidth estimations are overshot and they they are adjusted based on the perceived packet loss, for instance.

Again, logs would help.