Users stop hearing each other with 1.3.0~657~g06e19e6~snapshot

[sdar]

Latest snapshot (1.3.0~657~g06e19e6) seems to make users stop hearing each other soon after connecting to a server (tested on 1.2.8 server).

Clients using windows 7(x64) and windows 8.1(x64) and 32 bit mumble snapshots.

[hacst]

Do you happen to know which snapshot you were updating from? Also did I understand you correctly that you are talking about new snapshot clients not a snapshot server?

[sdar]

I'm pretty sure it was from 628... not sure about the other users.

4 users were having the issue we rolled back to 628 and it works fine now... i can test 652 if you want.

Server is running on 1.2.8, clients are running 1.3 snapshots.

The clients using 1.2.8 or older 1.3 snapshots seems to work fine, the users with 657 snapshots stop hearing other users soon after connecting the server.

[hacst]

Ok. That would mean candidates would be fcb908b7571db9f4e98d2776f449cc651afdca5e...06e19e6fb191afa794f8018b67252940bc097fdd . Nothing really jumps out at me. Most of the "critical" changes are server-side or would show itself in not being able to connect at all.

[hacst]

Some more questions:

• Is it reproducible?
• Does it happen to all users at once?
• Is it permanent and does a reconnect fix it?
• Is there any indication as to the trigger. Maybe some (specific) user joining?

[sdar]

628 works 652 and 657 have this bug, there's no 647 nor 650 on windows builds.

[sdar]

It is reproducible, I'm testing on a 1.2.5 linux server and on a 1.2.8 windows server soon after connecting i stop hearing other users.

Users using stable clients, 628 or older snapshots have no problems at all.

reconnecting seems to temporary fix it but it fails some minutes after each reconnect.

I'm trying to find what is triggering the issue, no luck yet... we're not doing anything special just talking and eventually it stop receiving others voices... it seems other users can still hear you (rest of us are now using 628 i'm the only one using 65x) even when you can't hear them.

When testing on the 1.2.8 server with just 2 users inside seems to take longer to fail, the other server with 8 users in the same channel seems to trigger the issue a lot faster.

[sdar]

So I'm still testing... sometimes it took just a few seconds other 5-10 minutes, it seems to stop receiving users voices (mic of others users are always off) but they still can hear you, and text chat seems to work fine too, mumble sounds and tts still works too.

[hacst]

Could you check your mumble log file (%APPDATA%\Mumble\console.txt) for suspicious entries or even better upload the part of it for a run that showed the problem somewhere? It might contain a hint on what is going.

[dafoxia]

Same Issue here too. Windows7 64 Bit last snapshot to (1.3.0~657~g06e19e6) and a other user Windows 8.1 64 Bit from last to (1.3.0~657~g06e19e6). Lokal Echo does not produce Echo. Server Echo is functional.

[sdar]

Sorry for the delay this is what i've seen in console so far.

Some old errors like

ServerHandler: Failed to remove UDP from QoS

class QPixmap __cdecl QPixmap::grabWindow(unsigned int,int,int,int,int) is deprecated, use QScreen::grabWindow() instead. Defaulting to primary screen.

But i have those errors on older versions too...

The only new messages I've seen so far is.

libpng warning: iCCP: known incorrect sRGB profile

but just showed once on the whole log.

Local echo doesn't produce echo on older snapshot so it's not a symptom of this bug.

The console look like this:

<W>2015-06-05 19:47:19.255 ServerHandler: Failed to remove UDP from QoS

<W>2015-06-05 19:47:21.152 OpenSSL Support: 1 (OpenSSL 1.0.1m 19 Mar 2015)

<W>2015-06-05 19:47:21.160 SSL: CA certificate filter applied. Filtered size: 120, original size: 120

<W>2015-06-05 19:47:21.160 ServerHandler: TLS cipher preference is "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:AES256-SHA:AES128-SHA"

<W>2015-06-05 19:47:21.160 ServerHandler: QOS2 loaded

This is already on console and mumble is working fine, eventually the issue is triggered so i do a reconnect

<W>2015-06-05 19:52:18.344 ServerHandler: Failed to remove UDP from QoS

<W>2015-06-05 19:52:18.410 OpenSSL Support: 1 (OpenSSL 1.0.1m 19 Mar 2015)

<W>2015-06-05 19:52:18.417 SSL: CA certificate filter applied. Filtered size: 160, original size: 160

<W>2015-06-05 19:52:18.417 ServerHandler: TLS cipher preference is "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:AES256-SHA:AES128-SHA"

<W>2015-06-05 19:52:18.418 ServerHandler: QOS2 loaded

This is already on console and mumble is working fine, eventually the issue is triggered so i do a reconnect

<W>2015-06-05 19:58:37.597 ServerHandler: Failed to remove UDP from QoS

<W>2015-06-05 19:58:37.669 OpenSSL Support: 1 (OpenSSL 1.0.1m 19 Mar 2015)

<W>2015-06-05 19:58:37.677 SSL: CA certificate filter applied. Filtered size: 200, original size: 200

<W>2015-06-05 19:58:37.677 ServerHandler: TLS cipher preference is "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:AES256-SHA:AES128-SHA"

<W>2015-06-05 19:58:37.677 ServerHandler: QOS2 loaded

<W>2015-06-05 20:04:50.360 ServerHandler: Failed to remove UDP from QoS

It seems clean to me, when the issue is triggered no error or message is shown on console.

[hacst]

Yeah. Looks clean. Would've been to easy I guess ;) We are currently trying to repro this locally.

[hacst]

@dafoxia What version does the server have? What platform is it running on?

[sdar]

I've tested on this two servers: Server version 1.2.8 OS: Windows server 2008 Server version 1.2.5 OS: Debian Wheezy

[cydactyl]

Had this same issue, reconnecting solved it temporarily, it's similar to #1541, except other people can still hear you, you just can't hear them.

[mkrautz]

We've reverted a Qt patch that caused these issues. A new snapshot, 1.3.0~658~g3d46634~snapshot, has that workaround in it.

We're trying to make a small reproducible case and report it upstream.

But for now, the bug should be patched in Mumble.

[davidebeatrici]

I assume this problem is not present anymore.