-
Notifications
You must be signed in to change notification settings - Fork 17
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
Comments
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. 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. |
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: VPS: I see no difference in the mumble logs between when it was working and now that its not. 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 |
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. |
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
The text was updated successfully, but these errors were encountered: