Not everyone hear all participants

Hi,

On 2 totally different jitsi-meet configurations we’ve been experiencing the same kind of issue as mentioned here.

We were 7 people, most of all of us could hear and talk to everyone, but one of them was heard by only one other (not the 6 others), always the same during the session, while the 1st could hear no one apart the 2nd.

I suggested the 1st guy re-connect : same situation.
I suggested the 1st guy switch from FF to Brave : same situation.

We all re-connected : same song.

This happened using 2 different servers and IP@.

Most of the participants use FF and/or Brave on Ubuntu/MacOS/Windows.
No mobile clients.
Planning to reproduce tomorrow afternoon when I can get enough connected testers.

Where could I fetch in the meantime?

That is interesting … which version do you use?

Here we are, on both instances:
jicofo 1.0-508-1 amd64 JItsi Meet COnference FOcus
jitsi-meet 1.0.4101-1 all WebRTC JavaScript video conferences
jitsi-meet-prosody 1.0.3729-1 all Prosody configuration for Jitsi Meet
jitsi-meet-web 1.0.3729-1 all WebRTC JavaScript video conferences
jitsi-meet-web-config 1.0.3729-1 all Configuration for web serving of Jitsi Meet
jitsi-videobridge 1126-1 amd64 WebRTC compatible SelectiveForwarding Unit (SFU)`

Maybe that is fixed in latest versions …

Thanks! That’s quite good news, I hope the latest versions are to be released soon.

In the mean time, is there something that can be done as a workaround for this strange behavior?

1 Like

You can try updating to latest from unstable, for sure will improve. Those are already running on meet.jit.si

OK, let’s try it. Seeing the list of new packages to be installed, I’m wondering whether there’s a dependency between jitsi and nginx.

upgradeJitsiUnstable.txt (18.4 KB)

Apache2 is the currently installed Webserver on this production host.

[Edit] Yes, nginx is then started which leads to troubles for apache2 such as:

(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80

Any chance you can tell us what exactly got improved? Maybe even pointing out the relevant commits?

Thanks!

Wait it should be nginx or apache. https://github.com/jitsi/jitsi-meet/blob/master/debian/control#L24

There were some fixes around initial offer here https://github.com/jitsi/jicofo/commits/master

One more question, when you say not everyone hear, is Firefox involved?

You’ve got the entire jitsi unstable installation log in my previous post.
I had no nginx installation before. Now yes. That makes me look at it… :wink:

Yes, as I mentioned initialy…

FF stands for Firefox. Brave is an alternative based on Chromium.

And it was the same without FF.

After switching to unstable, still the same problem!

jicofo                            1.0-535-1
jitsi-meet                        1.0.4311-1
jitsi-meet-prosody                1.0.3911-1
jitsi-meet-turnserver             1.0.3911-1
jitsi-meet-web                    1.0.3911-1
jitsi-meet-web-config             1.0.3911-1
jitsi-videobridge                 1132-1
prosody                           0.10.0-1build1

We just switched to meet.jit.si and everything’s fine. We’d like to use our instance instead. What informations do you need to help investigate?
Thanks.

[EDIT] So far, our instance is just not usable for more than 6 people… :roll_eyes:

Hi,

Separate group here with the same issue. We held an hour-long meeting on meet.jit.si for about a dozen people 3 hours ago. We’re all in the same city in New England.

Specifically User 1 and User 2 (Mac, Safari 13.1) reported not hearing specifically User 3 (OS X 10.12.4, Chrome 80.0.3987.163) after about 30 min into the call (no problem before this point). Most other users, including User 4, reported being able to hear User 3 throughout the call (so it’s not User 3’s mic problem). User 1 and User 2 was able to hear User 4 and other users throughout the call (so it’s not User 1 and User 2’s audio problem).

User 4 (iOS 13.3.1) and User 5 reported not hearing User 2, even though User 2 tried to speak.

In case it matters, someone’s screen was shared throughout (Linux, Brave 1.7.90 Chromium: 80.0.3987.163). We are not aware of anything happening at the 30 min mark that may have led to the problem appearing.

Someone else also recently mentioned the issue here.

Hey there, we are aware of an issue where Safari (both desktop and mobile) users are not able to hear some of the other participants in the call. This issue would start happening as soon as the call starts.

From your description, it looks like users 1 and 2 noticed the issue 30 mins into the call. Is it possible that user 3 wasn’t an active speaker until then ? If that is the case, we have a way of reproducing this so that we can figure out what is happening in this case.

1 Like

In the past, I had only very few times problems of one participant not being able to hear the others. Typically, force-reload in Chromium helped.

Unfortunately, after upgrading from 2.0.5390-3 to 2.0.5870-1, the situation became worse. Today, we (eight participants, all Chromium or similar) tried for half an hour to have audio for all, but it was not possible.

It looked like the last person joining the meeting couldn’t hear others at all. Also, some people heart others, but not all etc.

I’ll go back to 2.0.5390-3 for now.

Do you have js console logs from the problem meeting?

No, but I can probably make a new meeting these days.
Is there anything particular, that might be interesting to watch for?

When someone is not hearing a participant, but the rest are hearing it write down the participant id that is not heard (from the local stats) and save the js console logs of the participant not hearing and send us that information.

I experience similar problems and I am able to reproduce it with three participants. All of them use chromium.

Steps to reproduce the problem:

  1. The moderator joins the meeting room, selects “I am the host” and authenticates himself.
  2. The second one joins the room.
  3. From now on at least one participants must be talking. It may work also if both are muted, but I am not sure of that.
  4. The third one has the following permission for the site hosting the meeting: Camera allow; Microphone allow; Sound automatic
  5. The third one joins the meeting and does not hear the others. However, the others can hear him.

As far as I checked for now, there are two ways to solve the problem:

  1. Set the permission for Sound to allow. Sometime the participants has to change the audio device from default to something else for this to take effect.
  2. Enable the lobby.