search

mumble-voip / mumble

Mumble is an open-source, low-latency, high quality voice chat software.
https://www.mumble.info
Other
6.28k stars 1.11k forks source link

Switching or editing channels makes you stuck #4706

Closed ethernity closed 3 years ago

ethernity commented 3 years ago

If you edit a channel in the Windows Client (1.3.3) you cant switch channels or edit anything anymore. A reconnect seems to help.

toby63 commented 3 years ago

Can you give some more details?

For example:

ethernity commented 3 years ago

Its after closing the window.

The CPU usage doesn't increase.

It seems that only the panel where you can see the channels and switch them is affected. You cant switch channels anymore, neither double clicking on a channel nor right click "join" seems to work. You cant edit a channel anymore. But you can delete a channel. Everything else seems wo work.

Krzmbrzl commented 3 years ago

@ethernity are you still able to send and receive text messages when this happens? Did you encounter this issue on multiple different servers or only a single one?

ethernity commented 3 years ago

In this state I can't send messages, even though its shown in the chat window. Otherwise it seems I can receive messages just fine. The bug shows on two fresh installed debian instances installed per apt-get install mumble-server . Surprisingly I just tested a fresh Windows Server and the bug does not seem to occur.

Krzmbrzl commented 3 years ago

So receiving messages works but messages you send never reach their destination? That's interesting.

In general it seems like the editing does somehow block your outgoing TCP connection to the server. Do you have the knowledge to debug the TCP connection on your device?

Are these server instances that you tested all on the same hardware and/or network?

ethernity commented 3 years ago

The Debian servers are on the same virtual server, so they are not on the same network as my home PC. I also checked the logs and it seems the messages never reach the server. For the Windows Server I used the same device as my client. Sadly I dont know how to debug the TCP connection.

Krzmbrzl commented 3 years ago

For the Windows Server I used the same device as my client.

Okay. In that case it's probably not too telling that this configuration worked :thinking:

Does audio communication with folks in your current channel still work?

ethernity commented 3 years ago

Yes audio communication still works.

Interestingly I just tried to replicate the bug with Mumla (Android Client) and the same seems to happen. So I guess its a server problem?

Krzmbrzl commented 3 years ago

Yes audio communication still works.

Okay that means that the UDP connection is not affected by this issue.

Interestingly I just tried to replicate the bug with Mumla (Android Client) and the same seems to happen. So I guess its a server problem?

Are others still able to change channel, write text messages, etc. when this happens to you? Have you been using Mumla from a different network (e.g. mobile instead of WiFi) than your PC?

ethernity commented 3 years ago

It seems switching seems to work just once or twice and then other users are stuck too. At least until they reconnect. Yes I've used Mumla from mobile and WiFi and its the same.

ethernity commented 3 years ago

It seems switching seems to work just once or twice and then other users are stuck too. At least until they reconnect.

Scratch that it seems too much switching makes you stuck too.

ethernity commented 3 years ago

I just tried tcpdump and I can confirm the packets arrive at the server. Sadly I dont have much more knowledge about this topic and the tools. I can just see there is a burst in the logging if I try to switch channels.

And just for fun I used the Murmur Static Linux Server (murmur-static_x86-1.3.3) instead of the debian package. This version does seem to work fine on the same server. At least a short test of editing channels, creating groups and switching channels seems to work.

Krzmbrzl commented 3 years ago

Have you tried using the -v option when starting the server? Maybe this will cause something meaningful to be printed to the logs.

I just tried tcpdump and I can confirm the packets arrive at the server. Sadly I dont have much more knowledge about this topic and the tools. I can just see there is a burst in the logging if I try to switch channels.

Okay so your messages arrive at the server but you don't see that reflected in your local client's UI? In that case so other users perhaps see you switching channels on their clients? Or are you stuck for them as well?

ethernity commented 3 years ago

Have you tried using the -v option when starting the server? Maybe this will cause something meaningful to be printed to the logs.

Just tried that, but it doesn't show any more messages than before. But I just found out in the log, that the package I installed is using an older version (1.2.8), than the static linux server.

Okay so your messages arrive at the server but you don't see that reflected in your local client's UI? In that case so other users perhaps see you switching channels on their clients? Or are you stuck for them as well?

I'm stuck for them as well, as I tried to say even the mumble server doesn't seem to recognize those commands.

ethernity commented 3 years ago

Quick update. I updated the virtual server to Debian 10 and the package has a newer version of the mumble server (1.3.0~git20190125.440b173+dfsg-2) and it seems to work fine now.

Krzmbrzl commented 3 years ago

Ah okay perfect :+1:

Then this was just a remnant of using an ancient (and by now unsupported) version. Thus I'll close this issue :point_up: