starred/mumble-mumble-voip
1
0
Fork 0
mirror of https://github.com/mumble-voip/mumble.git synced 2026-03-03 00:46:56 -05:00
Code Issues 459 Projects Packages Wiki Activity

Randomly losing audio output from all users in channel #3062

New issue
Open
opened 2026-02-20 22:17:25 -05:00 by deekerman · 22 comments
deekerman commented 2026-02-20 22:17:25 -05:00
Owner
Copy link

Originally created by @Shaddycat on GitHub (Oct 25, 2025).

Description

My wife and I run Linux (OpenSUSE and Mint) and have both encountered an issue with Mumble where randomly one of us will stop receiving audio output from all users within a channel. The solution is to disconnect from the server and reconnect.
Noticeably, our friend who joins us runs Windows 11 and has experienced no such issue.

Steps to reproduce

  1. Open Mumble and connect to any active channel
  2. Wait until you can no longer hear any users within the channel

Mumble version

No response

Mumble component

Client

OS

Linux

Reproducible?

Yes

Additional information

No response

Relevant log output

Screenshots

No response

Originally created by @Shaddycat on GitHub (Oct 25, 2025). ### Description My wife and I run Linux (OpenSUSE and Mint) and have both encountered an issue with Mumble where randomly one of us will stop receiving audio output from all users within a channel. The solution is to disconnect from the server and reconnect. Noticeably, our friend who joins us runs Windows 11 and has experienced no such issue. ### Steps to reproduce 1. Open Mumble and connect to any active channel 2. Wait until you can no longer hear any users within the channel ### Mumble version _No response_ ### Mumble component Client ### OS Linux ### Reproducible? Yes ### Additional information _No response_ ### Relevant log output ```shell ``` ### Screenshots _No response_
deekerman commented 2026-02-20 22:17:27 -05:00
Author
Owner
Copy link

@Krzmbrzl commented on GitHub (Oct 25, 2025):

This sounds as if there was a UDP issue on the client-side...

When this happens, do any of the indicator lights still light up? Does your own indicator light up when you talk during times when this happens?

@Krzmbrzl commented on GitHub (Oct 25, 2025): This sounds as if there was a UDP issue on the client-side... When this happens, do any of the indicator lights still light up? Does your own indicator light up when you talk during times when this happens?
deekerman commented 2026-02-20 22:17:27 -05:00
Author
Owner
Copy link

@Shaddycat commented on GitHub (Oct 26, 2025):

None of the indicator lights for other users light up, but my own indicator light does.

@Shaddycat commented on GitHub (Oct 26, 2025): None of the indicator lights for other users light up, but my own indicator light does.
deekerman commented 2026-02-20 22:17:27 -05:00
Author
Owner
Copy link

@Krzmbrzl commented on GitHub (Oct 26, 2025):

Do others still hear you, when you don't hear them?

@Krzmbrzl commented on GitHub (Oct 26, 2025): Do others still hear you, when you don't hear them?
deekerman commented 2026-02-20 22:17:27 -05:00
Author
Owner
Copy link

@Shaddycat commented on GitHub (Oct 26, 2025):

They can still hear me

@Shaddycat commented on GitHub (Oct 26, 2025): They can still hear me
deekerman commented 2026-02-20 22:17:27 -05:00
Author
Owner
Copy link

@Krzmbrzl commented on GitHub (Oct 27, 2025):

Hm. Do you get any kind of message in Mumble's chat window about a switch from UDP to TCP?

And can the same problem be reproduced on a different server?

@Krzmbrzl commented on GitHub (Oct 27, 2025): Hm. Do you get any kind of message in Mumble's chat window about a switch from UDP to TCP? And can the same problem be reproduced on a different server?
deekerman commented 2026-02-20 22:17:27 -05:00
Author
Owner
Copy link

@Shaddycat commented on GitHub (Oct 29, 2025):

I don't get any messages or see any notification anywhere when it occurs. I have no way of knowing when it's happened until one of them messages me and says they're responding to me but I don't seem to hear them.

I haven't tested in another server, so let me run some tests elsewhere and see what happens.

@Shaddycat commented on GitHub (Oct 29, 2025): I don't get any messages or see any notification anywhere when it occurs. I have no way of knowing when it's happened until one of them messages me and says they're responding to me but I don't seem to hear them. I haven't tested in another server, so let me run some tests elsewhere and see what happens.
deekerman commented 2026-02-20 22:17:27 -05:00
Author
Owner
Copy link

@Shaddycat commented on GitHub (Oct 31, 2025):

Well I've tested on another server for an extended duration of time and didn't encounter the problem, so the issue must be on my server. I guess I wouldn't know what the cause is though. Nothing in the mumble logs.

@Shaddycat commented on GitHub (Oct 31, 2025): Well I've tested on another server for an extended duration of time and didn't encounter the problem, so the issue must be on my server. I guess I wouldn't know what the cause is though. Nothing in the mumble logs.
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@Krzmbrzl commented on GitHub (Nov 1, 2025):

Which version of the Mumble server are you using?
One thing to check would be whether forcing Mumble to use TCP for audio resolves the problem. In order for that to work, you would have to use a firewall to block all UDP traffic on your client machine. That should cause the client to switch to TCP mode, which in turn should make the server switch as well.

@Krzmbrzl commented on GitHub (Nov 1, 2025): Which version of the Mumble server are you using? One thing to check would be whether forcing Mumble to use TCP for audio resolves the problem. In order for that to work, you would have to use a firewall to block all UDP traffic on your client machine. That should cause the client to switch to TCP mode, which in turn should make the server switch as well.
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@Shaddycat commented on GitHub (Nov 1, 2025):

Looks like I'm on 1.3.0. This is from the official Ubuntu "mumble-server" apt package.

root@mumble:~# murmurd -version
<F>2025-11-01 20:59:33.192 murmurd -- 1.3.0+dfsg-1ubuntu0.1

I'm suspecting first I should update the server to the newest version before I try anything else. 1.3.0 is very old by this point. I don't see a Linux server release in the latest releases though.

@Shaddycat commented on GitHub (Nov 1, 2025): Looks like I'm on 1.3.0. This is from the official Ubuntu "mumble-server" apt package. ``` root@mumble:~# murmurd -version <F>2025-11-01 20:59:33.192 murmurd -- 1.3.0+dfsg-1ubuntu0.1 ``` I'm suspecting first I should update the server to the newest version before I try anything else. 1.3.0 is very old by this point. I don't see a Linux server release in the latest releases though.
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@Krzmbrzl commented on GitHub (Nov 1, 2025):

 I don't see a Linux server release in the latest releases though.

Unfortunately, we don't have any Linux packages (yet). However, you can obtain the latest server version from Doclerhub.

It's unclear whether this will actually fix the issue but I believe it's certainly worth a shot.

@Krzmbrzl commented on GitHub (Nov 1, 2025): >  I don't see a Linux server release in the latest releases though. Unfortunately, we don't have any Linux packages (yet). However, you can obtain the latest server version from Doclerhub. It's unclear whether this will actually fix the issue but I believe it's certainly worth a shot.
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@Shaddycat commented on GitHub (Nov 3, 2025):

The update didn't fix it, so I will test with TCP instead of UDP. Is there any reason I can't just use the tick box in the settings to force TCP mode?

@Shaddycat commented on GitHub (Nov 3, 2025): The update didn't fix it, so I will test with TCP instead of UDP. Is there any reason I can't just use the tick box in the settings to force TCP mode?
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@Krzmbrzl commented on GitHub (Nov 4, 2025):

Is there any reason I can't just use the tick box in the settings to force TCP mode?

I'm not 100% sure whether this will also cause the server to switch to TCP (as I believe the client keeps sending UDP pings). But it would certainly be a good start to just try that (and then monitor for Mumble UDP packets)

@Krzmbrzl commented on GitHub (Nov 4, 2025): > Is there any reason I can't just use the tick box in the settings to force TCP mode? I'm not 100% sure whether this will also cause the server to switch to TCP (as I believe the client keeps sending UDP pings). But it would certainly be a good start to just try that (and then monitor for Mumble UDP packets)
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@floyd-fuh commented on GitHub (Nov 13, 2025):

Just wanted to add a +1, me too. I have the issue for longer than 3 weeks. I would have opened a new issue because I'm on MacOS, but the symptoms are identical so I thought I leave it here.

Identical symptoms:

  • I stop receiving audio output from all users within a channel (the other users are on Linux and usually run on older versions of Mumble client, e.g. one is version 1.5.517). Sometimes I also realised that I only loose audio from some users, not all of them.
  • None of the indicator lights for other users light up, but my own indicator light does.
  • They can still hear me, but I can't hear them
  • I don't get any messages or see any notification anywhere when it occurs. I have no way of knowing when it's happened until one of them messages me and says they're responding to me but I don't seem to hear them.
  • TCP mode did not solve the problem. Also changing various settings in my client or the other clients didn't work.

Differences:

  • I run on MacOS Sequioa 15.7.2 (but the problem was also on previous Sequioa versions)
  • On MacOS Mumble client 1.5.735 (olders didn't work any better)
  • Linux Mumble server version 1.5.735 now (1.3.4-4+b1 to 1.5.735-5 change recently...)
  • Sometimes I can hear them in the beginning and then suddenly I stop hearing them (without any indicator)
  • In certain cases the Mumble client then finally crashes by now, but only rarely.
  • This is going through a VPN, but I doubt very much this is the problem as it used to work perfectly over VPN with Mumble before (we've been using this setup for 6 years) and I also checked with lower VPN-MTU etc.

Thanks a lot for the Server hint!

I guess we're going to downgrade the Linux Mumble server for now and check if that helps.

Let me know if you would like me to look into Wireshark or such...

One speculation: Maybe people start to migrate from Debian 12 to 13 (like us) and therefore installed Mumble server version v1.5.735 that has this issue... but can't confirm that yet.

@Shaddycat - Can you check which version the server is running on (in the client go to Server - Information) that has no issues with the audio?

@floyd-fuh commented on GitHub (Nov 13, 2025): Just wanted to add a +1, me too. I have the issue for longer than 3 weeks. I would have opened a new issue because I'm on MacOS, but the symptoms are identical so I thought I leave it here. Identical symptoms: * I stop receiving audio output from all users within a channel (the other users are on Linux and usually run on older versions of Mumble client, e.g. one is version 1.5.517). Sometimes I also realised that I only loose audio from some users, not all of them. * None of the indicator lights for other users light up, but my own indicator light does. * They can still hear me, but I can't hear them * I don't get any messages or see any notification anywhere when it occurs. I have no way of knowing when it's happened until one of them messages me and says they're responding to me but I don't seem to hear them. * TCP mode did *not* solve the problem. Also changing various settings in my client or the other clients didn't work. Differences: * I run on MacOS Sequioa 15.7.2 (but the problem was also on previous Sequioa versions) * On MacOS Mumble client 1.5.735 (olders didn't work any better) * Linux Mumble server version 1.5.735 now (1.3.4-4+b1 to 1.5.735-5 change recently...) * Sometimes I can hear them in the beginning and then suddenly I stop hearing them (without any indicator) * In certain cases the Mumble client then finally crashes by now, but only rarely. * This is going through a VPN, but I doubt very much this is the problem as it used to work perfectly over VPN with Mumble before (we've been using this setup for 6 years) and I also checked with lower VPN-MTU etc. Thanks a lot for the Server hint! I guess we're going to downgrade the Linux Mumble server for now and check if that helps. Let me know if you would like me to look into Wireshark or such... One speculation: Maybe people start to migrate from Debian 12 to 13 (like us) and therefore installed Mumble server version v1.5.735 that has this issue... but can't confirm that yet. @Shaddycat - Can you check which version the server is running on (in the client go to Server - Information) that has no issues with the audio?
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@Krzmbrzl commented on GitHub (Nov 13, 2025):

I guess we're going to downgrade the Linux Mumble server for now and check if that helps.

Please report back on whether this made any difference.

Linux Mumble server version 1.5.735 now (1.3.4-4+b1 to 1.5.735-5 change recently...)

Did the problem only start appearing after the switch?

Let me know if you would like me to look into Wireshark or such...

It'd be amazing if you could check UDP packets between the server and your client. Specifically, whether there are any UDP packets that the server sends to your client but your client doesn't receive any of them

General questions:

  • Are you using positional audio when these issues happen or do they happen within regular communication (without any plugin being linked to a game)?
  • When you can't hear other folks, can they still hear each other?
@Krzmbrzl commented on GitHub (Nov 13, 2025): > I guess we're going to downgrade the Linux Mumble server for now and check if that helps. Please report back on whether this made any difference. > Linux Mumble server version 1.5.735 now (1.3.4-4+b1 to 1.5.735-5 change recently...) Did the problem only start appearing after the switch? > Let me know if you would like me to look into Wireshark or such... It'd be amazing if you could check UDP packets between the server and your client. Specifically, whether there are any UDP packets that the server sends to your client but your client doesn't receive any of them ---- General questions: - Are you using positional audio when these issues happen or do they happen within regular communication (without any plugin being linked to a game)? - When you can't hear other folks, can they still hear each other?
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@floyd-fuh commented on GitHub (Nov 17, 2025):

I guess we're going to downgrade the Linux Mumble server for now and check if that helps.

Please report back on whether this made any difference.

Yeah our admin has to find a time slot for the downgrade... let's hope it's happening this year... 😄

Linux Mumble server version 1.5.735 now (1.3.4-4+b1 to 1.5.735-5 change recently...)

Did the problem only start appearing after the switch?

Unfortunately we don't know for sure because we can't remember the dates precisely. But I checked some logs and I guess we also had problems before the change, but not 100% sure.

Let me know if you would like me to look into Wireshark or such...

It'd be amazing if you could check UDP packets between the server and your client. Specifically, whether there are any UDP packets that the server sends to your client but your client doesn't receive any of them

Just confirmed with Wireshark, UDP packets are incoming and outgoing. The network is not the problem. The client is not outputting the audio apparently.

General questions:

* Are you using positional audio when these issues happen or do they happen within regular communication (without any plugin being linked to a game)?

No positional audio, just regular communication (no plugins, no games)

* When you can't hear other folks, can they still hear each other?

Yes (also make sense as the UDP packets are going out)

@floyd-fuh commented on GitHub (Nov 17, 2025): > > I guess we're going to downgrade the Linux Mumble server for now and check if that helps. > > Please report back on whether this made any difference. Yeah our admin has to find a time slot for the downgrade... let's hope it's happening this year... 😄 > > Linux Mumble server version 1.5.735 now (1.3.4-4+b1 to 1.5.735-5 change recently...) > > Did the problem only start appearing after the switch? > Unfortunately we don't know for sure because we can't remember the dates precisely. But I checked some logs and I guess we also had problems before the change, but not 100% sure. > > Let me know if you would like me to look into Wireshark or such... > > It'd be amazing if you could check UDP packets between the server and your client. Specifically, whether there are any UDP packets that the server sends to your client but your client doesn't receive any of them > Just confirmed with Wireshark, UDP packets are incoming and outgoing. The network is not the problem. The client is not outputting the audio apparently. > General questions: > > * Are you using positional audio when these issues happen or do they happen within regular communication (without any plugin being linked to a game)? > No positional audio, just regular communication (no plugins, no games) > * When you can't hear other folks, can they still hear each other? Yes (also make sense as the UDP packets are going out)
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@Shaddycat commented on GitHub (Nov 27, 2025):

Update: I changed my client to force use TCP and haven't experienced the issue since. It has been probably about two weeks of testing every other day on average. My wife did not make the change and continued to experience it. I have changed her over two days ago, no issue yet. But the test duration is too short I think to confirm anything on her end.

If forcing TCP fixes it, what would be recommended to get UDP working instead?

@Shaddycat commented on GitHub (Nov 27, 2025): Update: I changed my client to force use TCP and haven't experienced the issue since. It has been probably about two weeks of testing every other day on average. My wife did not make the change and continued to experience it. I have changed her over two days ago, no issue yet. But the test duration is too short I think to confirm anything on her end. If forcing TCP fixes it, what would be recommended to get UDP working instead?
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@Krzmbrzl commented on GitHub (Dec 12, 2025):

If forcing TCP fixes it, what would be recommended to get UDP working instead?

That depends on the reason why UDP doesn't work. And I have no idea why that might be the case...

@Krzmbrzl commented on GitHub (Dec 12, 2025): > If forcing TCP fixes it, what would be recommended to get UDP working instead? That depends on the reason why UDP doesn't work. And I have no idea why that might be the case...
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@tparikka commented on GitHub (Dec 30, 2025):

I've been running into similar issues on my MacBook.

Client Side:

  • MacBook Air M4
  • MacOS Tahoe 26.2
  • Mumble Client 1.5.857

Server Side:

  • Server running Protocol 1.4.0, Release/OS Unknown
  • Users 28/2000
  • Audio Codec Opus using 35.1 kBits/s of 36.0 allowed
  • TCP Control/Voice Using TLS 1.3 cipher TLS_AES_256_GCM_SHA384 with 136.1ms latency, PFS says yes
  • Have tried both TCP and UDP

When I'm on Windows, I don't run into any issues at all. This issue only presents on my MacBook Air. It comes and goes - I'll be hearing audio fine and then it'll drop for minutes at a time. I won't see any indications in the client of anyone speaking.

@tparikka commented on GitHub (Dec 30, 2025): I've been running into similar issues on my MacBook. Client Side: - MacBook Air M4 - MacOS Tahoe 26.2 - Mumble Client 1.5.857 Server Side: - Server running Protocol 1.4.0, Release/OS Unknown - Users 28/2000 - Audio Codec Opus using 35.1 kBits/s of 36.0 allowed - TCP Control/Voice Using TLS 1.3 cipher TLS_AES_256_GCM_SHA384 with 136.1ms latency, PFS says yes - Have tried both TCP and UDP When I'm on Windows, I don't run into any issues at all. This issue only presents on my MacBook Air. It comes and goes - I'll be hearing audio fine and then it'll drop for minutes at a time. I won't see any indications in the client of anyone speaking.
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@tparikka commented on GitHub (Jan 10, 2026):

Are there any kinds of diagnostics I could either obtain myself or request from my server admin to help in tracking this issue down?

@tparikka commented on GitHub (Jan 10, 2026): Are there any kinds of diagnostics I could either obtain myself or request from my server admin to help in tracking this issue down?
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@Krzmbrzl commented on GitHub (Jan 11, 2026):

I guess classic UDP connectivity debugging suggestions apply (log incoming and outcoming packets on client and server to see where the issue lies - presumably the client but this would make sure) and then trying to figure out the reason for that. I have never done something like that before, so I can't really give good advice on how to go about this 👀

@Krzmbrzl commented on GitHub (Jan 11, 2026): I guess classic UDP connectivity debugging suggestions apply (log incoming and outcoming packets on client and server to see where the issue lies - presumably the client but this would make sure) and then trying to figure out the reason for that. I have never done something like that before, so I can't really give good advice on how to go about this :eyes:
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@tparikka commented on GitHub (Jan 11, 2026):

I’ve tried it in TCP mode and run into the same issues, so I’m not sure it’s UDP specific.

@tparikka commented on GitHub (Jan 11, 2026): I’ve tried it in TCP mode and run into the same issues, so I’m not sure it’s UDP specific.
deekerman commented 2026-02-20 22:17:28 -05:00
Author
Owner
Copy link

@Krzmbrzl commented on GitHub (Jan 11, 2026):

Hm, then your issue seems to be different from the one discussed in this thread… You could try whether you are still able to ping the machine hosting the Mumble server when you encounter this issue. If that's the case, please open a separate issue here. If you can't ping during the times you don't hear anything, then it seems like some sort of network interruption (maybe try a wired connection if you are currently using WiFi)

@Krzmbrzl commented on GitHub (Jan 11, 2026): Hm, then your issue seems to be different from the one discussed in this thread… You could try whether you are still able to `ping` the machine hosting the Mumble server when you encounter this issue. If that's the case, please open a separate issue here. If you can't ping during the times you don't hear anything, then it seems like some sort of network interruption (maybe try a wired connection if you are currently using WiFi)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
weblate-translation-update
1.6.x
1.5.x
backport/1.5.x/pr-7080
backport/1.5.x/pr-6875
backport/1.5.x/pr-6879
backport/1.5.x/pr-6859
test-ci-win-fail
backport/1.5.x/pr-6789
backport/1.5.x/pr-6841
backport/1.5.x/pr-6832
backport/1.5.x/pr-6825
backport/1.5.x/pr-6809
backport/1.5.x/pr-6790
backport/1.5.x/pr-6777
backport/1.5.x/pr-6747
backport/1.5.x/pr-6775
backport/1.5.x/pr-6748
backport/1.5.x/pr-6769
backport/1.5.x/pr-6750
backport/1.5.x/pr-6744
backport/1.5.x/pr-6742
backport/1.5.x/pr-6728
backport/1.5.x/pr-6723
backport/1.5.x/pr-6700
backport/1.5.x/pr-6702
backport/1.5.x/pr-6703
backport/1.5.x/pr-6694
appveyor-fxc-dll-symbol-workaround
1.4.x
v1.6.870
v1.5.857
v1.5.735
v1.5.634
v1.5.629
v1.5.613
v1.5.517
v1.4.287
v1.4.274
v1.4.230
1.4.0-release-candidate-01
1.4.0-development-snapshot-006
1.4.0-development-snapshot-005
1.4.0-development-snapshot-004
1.4.0-development-snapshot-003
1.4.0-development-snapshot-002
1.3.4
1.4.0-development-snapshot-001
1.3.3
1.3.2
1.3.1
1.3.1-rc1
1.3.0
1.3.0-rc2
1.3.0-rc1
1.2.20
1.2.19
1.2.18
1.2.17
1.2.16
1.2.15
1.2.14
1.2.13
1.2.12
1.2.11
1.2.10
1.2.9
1.2.8
1.2.7
1.2.6
1.2.5
1.2.4
1.2.4-rc1
1.2.4-beta1
1.2.3
1.2.3-rc3
1.2.3-rc2
1.2.3-rc1
1.2.2
1.2.1
1.2.0
1.2.0beta2
1.2.0beta1
1.1.8
Labels
Clear labels   
GlobalShortcuts

   
Hacktoberfest

   
accessibility

   
acl

   
asio

   
audio

   
bonjour

   
bsd

   
bug

   
build

   
certificate

   
ci

   
client

   
code

   
documentation

   
external-bug

   
feature-request

   
gRPC

   
github

   
good first issue

   
help wanted

   
help-needed

   
ice

   
installer

   
linux

   
macOS

   
needs-ckeck-with-latest-version

   
needs-more-input

   
overlay

   
positional audio

   
priority/P0 - Blocker

   
priority/P1 - Critical

   
priority/P2 - Important

   
priority/P3 - Somewhat important

   
priority/P4 - Low

   
public-server-registration

   
qt

   
recording

   
release-management

   
server

   
stale-no-response

   
stale-support

   
support

   
task

   
test

   
theme

   
translation

   
triage

   
ui

   
windows

   
wontfix

   
x64
No labels
GlobalShortcuts
Hacktoberfest
accessibility
acl
asio
audio
bonjour
bsd
bug
build
certificate
ci
client
code
documentation
external-bug
feature-request
gRPC
github
good first issue
help wanted
help-needed
ice
installer
linux
macOS
needs-ckeck-with-latest-version
needs-more-input
overlay
positional audio
priority/P0 - Blocker
priority/P1 - Critical
priority/P2 - Important
priority/P3 - Somewhat important
priority/P4 - Low
public-server-registration
qt
recording
release-management
server
stale-no-response
stale-support
support
task
test
theme
translation
triage
ui
windows
wontfix
x64
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/mumble-mumble-voip#3062
No description provided.