Mumble loses sounds after a while

[mumble-voip]

Like the title says my Mumble loses the sounds after a few minutes and it also stops showing that others are speaking but it says and gives alert sound that somebody joined the channel. I have tested in many Mumble servers and every time it stops working properly. I don't know what is causing this problem but it occurs many times in a day. To repair this problem I have to reconnect to server but it won't stay long, after a few minutes I have to reconnect again.

I really hope that you can help me with this, I really don't know what to do with this. I have tried to run repair and re-installed the mumble but none have worked. I use Speakers (Realtek High Definition Audio) as mumble's output device.

Sincerelly

KeKsiMonsteri

This ticket has been migrated from sourceforge. It is thus missing some details like original creator etc. The original is at https://sourceforge.net/p/mumble/bugs/1031/ .

*The following attachments were added on the original item:

• https://sourceforge.net/p/mumble/bugs/1031/attachment/DxDiag.txt*

[TurBoss]

hi, latest version available from ppa 1.3.0-935 ubuntu 15.10 and i'm getting the same problem after a while the client stops receiving sound (sry no mic) but alerts leaves and joins and text msgs ( notification sound )

where does mumble client store its logs or configs so I can upload? nothing in ~/.mumble or similar thx!

EDIT: found verbose mode :) will upload a log EDIT2: restart the client solves the problem until next to come :(

[TurBoss]

It happened after a long time deafened nothing shown in verbosemode

[davidebeatrici]

Hi, is the issue still there?

[coldfix]

Happening for me as well. I'm running murmur in docker with alpine. Anything else I can do to provide additional debug information?

(The same container setup was running fine few months ago with just older version of murmur)

EDIT: Wait I just realized mine may be a different issue: it seems to be a server side problem as this happens only on one server. On other servers I can talk without restarting mumble client.

[Krzmbrzl]

Is there a way to reproduce this? @coldfix do you know which specific server that was?

[coldfix]

@Krzmbrzl, I haven't encountered this problem in the last year or so, but I also haven't used the server very often in this period, so it's hard to say if the issue still exists. I will report back should I encounter it again.

For reference, the server was created by the following rather convoluted setup (sorry for that):

docker-compose.yml

version: "3"
services:
  murmur:
    build: modules/murmur
    restart: always
    volumes:
      - /etc/letsencrypt:/etc/letsencrypt
      - ./etc/murmur:/etc/murmur
      - ./var/murmur/log:/var/log/murmur
      - ./var/murmur/lib:/var/lib/murmur
    ports:
      - "64738:64738/tcp"
      - "64738:64738/udp"
    cap_drop:
      - all
    cap_add:
      - chown
      - dac_override
      - setgid
      - setuid

modules/murmur/Dockerfile

FROM alpine:3.6

COPY . /murmur
WORKDIR /murmur
VOLUME /etc/murmur
VOLUME /var/lib/murmur
VOLUME /var/log/murmur

RUN apk update && \
    apk add -u tini sqlite murmur icu-libs openssl

EXPOSE 64738/tcp
EXPOSE 64738/udp

ENTRYPOINT ["/sbin/tini", "--", "/murmur/init.sh"]
CMD ["/usr/bin/murmurd", "-fg", "-v"]

modules/murmur/init.sh

#! /bin/sh
set -ex

# Get the mounted config file if it exists:
[ -f /etc/murmur/murmur.ini ] && cp /etc/murmur/murmur.ini /etc/murmur.ini

# Create data folders and adjust permissions:
mkdir -p /var/lib/murmur && chown -R murmur:murmur /var/lib/murmur
mkdir -p /var/log/murmur && chown -R murmur:murmur /var/lib/murmur

# Setup an initial database file:
if [ ! -f /var/lib/murmur/murmur.sqlite ]; then
    /etc/murmur/sql_init_db.sh
fi

# Spawn process
exec "$@"

etc/murmur/murmur.ini

database=/var/lib/murmur/murmur.sqlite
dbus=session
ice="tcp -h 127.0.0.1 -p 6502"
logfile=/var/log/murmur/murmur.log
pidfile=/var/run/murmur/murmur.pid
welcometext="<br />Welcome to this server running <b>Murmur</b>.<br />Enjoy your stay!<br />"
port=64738
host=0.0.0.0
serverpassword=XXXXX
bandwidth=72000
users=100
rememberchannel=false
defaultchannel=1
sslCert=/etc/letsencrypt/live/coldfix.de/cert.pem
sslKey=/etc/letsencrypt/live/coldfix.de/privkey.pem
sslCA=/etc/letsencrypt/live/coldfix.de/fullchain.pem
uname=murmur

[Ice]
Ice.Warn.UnknownProperties=1
Ice.MessageSizeMax=65536

etc/murmur/sql_init_db.sh

#! /bin/sh
set -e

port=64738
DB_FILE=/var/lib/murmur/murmur.sqlite

add_channel() {
    sqlite3 $DB_FILE "
        insert into channels
        (server_id, channel_id, parent_id, name, inheritacl) values
        (1, $1, 0, \"$3\", 1);
    "
    sqlite3 $DB_FILE "
        insert into channel_info
        (server_id, channel_id, key, value) values
        (1, $1, 0, \"\"),
        (1, $1, 1, \"$2\");
    "
}

/etc/murmur/sql_create_default_db.sh
add_channel 1  0 "Kätzchen"
add_channel 2 20 "Krümelchen"
add_channel 3 40 "Flauschetierchen"
add_channel 4 60 "Fette Torten"

etc/murmur/sql_create_default_db.sh

#! /bin/sh
set -ex

# This script serves to let murmur run shortly in order to create its default database file.

murmurd

# NOTE: for some reason there is no /var/run/murmur/murmur.pid
sleep 1
PID="`pgrep murmurd`"

kill $PID
wait $PID || echo "Exit status $?"
sleep 1

[Krzmbrzl]

Thank you for the status update @coldfix :)

In this case I'll close this issue in the hope that it has been fixed. Should you encounter this issue again, please come back here and we'll re-open the issue again.

[rteusner]

Seems to happen again, at least for my client (on Windows, v 1.4.230). Server version is 1.3.4. (in docker image https://hub.docker.com/r/m0wer/murmur )

[Krzmbrzl]

A few things to try:

1. Enable Force TCP mode in your client's settings
2. If the above doesn't help, please try temporarily blocking all UDP traffic through your firewall (see also https://social.technet.microsoft.com/Forums/en-US/39eb105a-4ca7-4003-aaed-f66b335cf024/windows-10-block-all-tcp-and-udp-port-and-allow-some-port but leave TCP alone - only UDP).
3. Please check the server info and tell me the reported packet loss after you have experienced the issue for a while. In theory the UDP packet loss should be somewhat high

To me this sounds as if the UDP connection somehow gets messed up and thus fails to deliver audio properly. However, for some reason it's not broken enough for Mumble to detect that something is wrong...

[rteusner]

Forcing TCP solved the issue.

Unchecking it brought back the issue, checking it again removed it again. We let it run with the issue for some time, but the server logs were empty on my colleagues server (probably some volume issue in the container). We will try once more tomorrow and I will send you logs once we get something. Thanks for your suggestion.

[Krzmbrzl]

Alright. That means that the issue is definitely related to the UDP connection breaking for some reason. However, I thought that there were some UDP pings being sent around to check for exactly this situation. I'll have to double-check the source code though

[davidebeatrici]

That's how it's supposed to work, indeed. Consider that ping packets are generally much smaller compared to voice ones, though.

[Krzmbrzl]

So you think that it could be that small UDP packets work fine whereas larger ones get corrupted?

[davidebeatrici]

Or even entirely dropped.

[ghost]

This needs tested with 1.4

[Krzmbrzl]

The problem should still be there as nothing has been done to fix it (afaik)

[z411]

I can confirm that it still happens with Mumble client 1.5.517 and Murmur server 1.4.0 or uMurmur server 0.2.20.

[do4bmw]

confirm , problem still there / win10 / Mumble CLient version 1.5.517

[RagingCactus]

This is happening to a user on my server, and forcing TCP mode seems to fix it. I strongly suspect this user is behind a carrier-grade NAT (CGN or CGNAT; see https://en.wikipedia.org/wiki/Carrier-grade_NAT) and/or Dual-Stack Lite (DS-Lite; see https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_(DS-Lite). This might explain how the connection gets dropped after a while, especially if the user doesn't speak, as in that case the NAT gateway might remove the port mapping to the specific user.

I understand from the other comments that Mumble is supposed to send ping packets to keep the connection alive, but maybe this gives someone a new idea.

Other users on the server do not have similar issues, and forcing TCP mode in the client for that user seems to work around the problem.

Just for completeness:

• Murmur server version: 1.4.287
• Mumble client version of the affected user: 1.4.287 on Windows