Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No sound from discord log shows "toMumble buffer full. Dropping packet" #24

Open
lordkitsuna opened this issue Aug 9, 2021 · 3 comments
Assignees
Labels
bug Something isn't working question Further information is requested

Comments

@lordkitsuna
Copy link

title says it all. as of today i suddenly can not hear any discord users. i have tried multiple restarts of the program and mumble server to no avail. they can hear me but any time they talk the log just spams "toMumble buffer full. Dropping packet" bridge and mumble server are both on the same machine and connect using 127.0.0.1 no external auth used

@Stieneee
Copy link
Owner

Hmmm. This one is going to be difficult to solve. I only typically see the toMumble buffer fill up when the connection between the bridge and the mumble server is dropped. The fact you are the same machine and audio is flowing in the opposite direction suggests there is a deeper problem.

Some quick high-level questions before I start making changes for you.
What version of the mumble server are you using?
Is there anything interesting in the mumble-server log?
Are you running the bridge in a docker container? Did you download the binary? Compile yourself?
Anything unique about the machine? Is it powerful enough?
Could you try running the bridge on another machine?

Ultimately it would be best if I could reproduce the issue on my end. Alternatively, I would be happy to instrument the code for some better observability.

@Stieneee Stieneee self-assigned this Aug 10, 2021
@Stieneee Stieneee added bug Something isn't working question Further information is requested labels Aug 10, 2021
@lordkitsuna
Copy link
Author

lordkitsuna commented Aug 11, 2021

The machine is no where near loaded here is some information. going to be honest i cant find the exact package version for my murmur and now i am questioning how i even installed it. apt does not appear to know about it but i dont see any git clones either its been up for some time i guess i hit a set and forget with it since it was working for so long. I can say its installed natively to the system and not in any kind of docker tho so i probably just downloaded the binary and cleared the download folder since then. i do have some info from the client server check.

Murmur:
Protocol 1.3.4
1.3.4-1 (X11)

VPS:
OS: Debian GNU/Linux 11 (bullseye) x86_64
Kernel: 5.10.0-8-amd64
CPU: Intel Xeon E5-2690 v3 (5) @ 2.599GHz
Memory: 369MiB / 9960MiB

I see no difference in the mumble logs between when it was working and now that its not.
<97:(-1)> New connection: 127.0.0.1:40986
2021-08-03 13:41:39.113 1 => <97:(-1)> Client version 1.3.0 (linux: gumble)
2021-08-03 13:41:39.116 1 => CELT codec switch ffffffff8000000b ffffffff80000010 (prefer ffffffff8000000b) (Opus 1)
2021-08-03 13:41:39.118 1 => <97:Discord-Bridge(-1)> Authenticated
2021-08-03 13:41:39.122 1 => <97:Discord-Bridge(-1)> Moved Discord-Bridge:97(-1) to Tavern-Gossip[1:0]
2021-08-03 17:21:08.793 1 => <95:LordKitsuna(1)> Connection closed: The remote host closed the connection [1]

this is the same i see in the logs once it was broken just the inital join and the later leaving nothing new or different.

EDIT: i just played with it some more and now i am getting "dgVoice: Error decoding opus data: buffer is too small
" spammed endlessly in the bridge terminal output. spam stops when no one on discord talks and starts again once anything is broadcast

@Stieneee
Copy link
Owner

Looked a little deeper into your issue this weekend. I have a couple of thoughts.

First, the word "buffer" in your first error message is a lie. The goroutine that is doing the audio mixing is only waiting 10 ms for the mumble client library to take the new audio message and send it. If you can reproduce the toMumble discord message it would be interesting is see if some of the mumble packets are getting through or if it's dropping all packets to mumble. The timestamps of the error message should give us a clue as to how many messages are making it through.

I took a close look at the code that handles packets to mumble and am reasonably happy with the implementation. That being said the timing is tight. If some packets are making it through the fix may be relaxing the timeout time on the outbound packets.

I have created a new branch where I have instrumented the code. There is a new docker-compose file that will stand up the bridge alongside Prometheus and Grafana which should give us some insight as to how many packets are travelling are actually being sent to mumble.

https://github.com/Stieneee/mumble-discord-bridge/tree/v0.5.0

As for your second error. Can you confirm that you are using the latest bridge? There was a critical patch to the way discord packets are decoded that can cause that opus error you mention that I fixed in a recent release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants