search

Stieneee / mumble-discord-bridge

A simple voice bridge between Mumble and Discord.
MIT License
153 stars 16 forks source link

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

Open lordkitsuna opened 3 years ago

lordkitsuna commented 3 years ago

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 commented 3 years ago

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.

lordkitsuna commented 3 years ago

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 commented 3 years ago

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.