Switching or editing channels makes you stuck #2090

Author

Owner

@toby63 commented on GitHub (Jan 19, 2021):

Can you give some more details?

For example:

Does the channel configuration window get stuck or is it after closing the config window?
Does your CPU usage increase?
Other activities are still possible?

@toby63 commented on GitHub (Jan 19, 2021): Can you give some more details? For example: - Does the channel configuration window get stuck or is it after closing the config window? - Does your CPU usage increase? - Other activities are still possible?

deekerman commented

Author

Owner

@ethernity commented on GitHub (Jan 20, 2021):

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.

@ethernity commented on GitHub (Jan 20, 2021): 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.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (Jan 21, 2021):

@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?

@Krzmbrzl commented on GitHub (Jan 21, 2021): @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?

deekerman commented

Author

Owner

@ethernity commented on GitHub (Jan 21, 2021):

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.

@ethernity commented on GitHub (Jan 21, 2021): 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.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (Jan 22, 2021):

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?

@Krzmbrzl commented on GitHub (Jan 22, 2021): 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?

deekerman commented

Author

Owner

@ethernity commented on GitHub (Jan 22, 2021):

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.

@ethernity commented on GitHub (Jan 22, 2021): 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.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (Jan 22, 2021):

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 🤔

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

@Krzmbrzl commented on GitHub (Jan 22, 2021): > 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?

deekerman commented

Author

Owner

@ethernity commented on GitHub (Jan 22, 2021):

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?

@ethernity commented on GitHub (Jan 22, 2021): 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?

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (Jan 22, 2021):

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?

@Krzmbrzl commented on GitHub (Jan 22, 2021): > 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?

deekerman commented

Author

Owner

@ethernity commented on GitHub (Jan 22, 2021):

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 on GitHub (Jan 22, 2021): 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.

deekerman commented

Author

Owner

@ethernity commented on GitHub (Jan 22, 2021):

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 on GitHub (Jan 22, 2021): > > > 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.

deekerman commented

Author

Owner

@ethernity commented on GitHub (Jan 22, 2021):

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.

@ethernity commented on GitHub (Jan 22, 2021): 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.

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (Jan 23, 2021):

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?

@Krzmbrzl commented on GitHub (Jan 23, 2021): 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?

deekerman commented

Author

Owner

@ethernity commented on GitHub (Jan 26, 2021):

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 on GitHub (Jan 26, 2021): > > > 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.

deekerman commented

Author

Owner

@ethernity commented on GitHub (Jan 26, 2021):

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.

@ethernity commented on GitHub (Jan 26, 2021): 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.

deekerman commented