24/7 music bot randomly stops transmitting until restarted

[Foxite]

I have a bot that is connected to voice channels and plays the same, 6-hour raw pcm file on loop 24/7. This works fine until it randomly stops playing. I have never observed this happening, only finding it silent when I join the channel. There are no exceptions or error events. I've had this problem basically since I started running it about 6 months ago, and nothing I've tried has permanently fixed it. Restarting the bot will temporarily fix it.

The bot runs in docker, and uses .NET 5.0. Testing with a shorter audio file reveals that it's not because my code doesn't loop the track properly.

While the bot is properly playing music, cpu usage for the dotnet process is about 25% which I've been told is normal. After the bot stops transmitting, cpu usage is less than 1%.

I'm not sure at all if this is a problem with dsharpplus, my code, or my internet, but I'm pretty much out of ideas for how to fix this. If you're curious and have spare time you can look at my code here

[OoLunar]

We are looking into completely remaking VNext. You're welcome to join our Discord to see what we currently have planned or to suggest any new features you'd like to see. Thanks for the bug report, I'll leave the issue open until the rewrite releases

[Foxite]

FWIW, I switched to another discord library and I'm still having this problem, so it's probably not caused by this library.

[OoLunar]

I've been having continuous trouble with Discord's voice gateway, so I'm generally unsure if there's an issue with Discord's voice gateway itself, if the lib has somehow been banned from receiving VOICE_STATE_UPDATE and VOICE_SERVER_UPDATE events or if there's just a deeply rooted lib bug that I have not yet found. I spent all day yesterday trying to fix a majority of VoiceNext bugs as a hotfix attempt, however, I didn't make any progress whatsoever.

If OTHER libs are starting to have issues with Discord's voice gateway, then that only confuses me more.

[loopyd]

This is a definite voice API bandwidth limitation as I see it happening outside of .NET in libraries like discord.py too. I have issues. So do many of the music bots. Discord has bandwith limits and they can and will kill a pipe at any time if a shard is using too much. i'd suggest killing the shard and restarting it once an hour automatically if the bots supposed to be in a channel to work around this. This seems to be connected to how much actual bandwidth is being used. You're being ratelinited which is exactly what this is. The voice pipeline is not intended to be used constantly as it consumes a lot of bandwidth. Limiting the bitrate on both the channel and the bot helps. Ive been able to stretch the time I've been able to keep it connected by setting the channel bitrate and the streaming in bitrate for both the bot and the channel to 96kbps. Trying to push down raw pcm to the API is also going to cause you to lose additional bandwidth. Encode it properly before pushing it down. Dont let the API do that for you. As you are going to unnessecarily rate limit yourself. You are going to lose voice quality and your bot is still going to be limited by this it's not something that we have control over it's discod limiting bandwidth usage. Choose a smart codec and push that downstream. Mux it before it hits the pipe so you are not sending what you should not. I am not going to suggest any rateliniting workarounds as it is a part of our API usage agreement not to circumvent or subsvert these limitations. You will have to reduce the bit rate of the bot in the channel and make sure that the proper encoder is selected to reduce the amount of bandwidth that is hitting the API to stay within the 24 hour limitations. That is the best you can do. You are going to lose voice quality so take your pick: - time connected - voice quality Cant have both.

…

On Apr 27, 2022, at 9:23 AM, Lunar Starstrum ***@***.***> wrote:  I've been having continuous trouble with Discord's voice gateway, so I'm generally unsure if there's an issue with Discord's voice gateway itself, if the lib has somehow been banned from receiving VOICE_STATE_UPDATE and VOICE_SERVER_UPDATE events or if there's just a deeply rooted lib bug that I have not yet found. I spent all day yesterday trying to fix a majority of VoiceNext bugs as a hotfix attempt, however, I didn't make any progress whatsoever. If OTHER libs are starting to have issues with Discord's voice gateway, then that only confuses me more. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[Foxite]

@loopyd Thanks for all the info. As for encoding transmitted audio, if I understand it correctly, audio is sent to Discord in Opus, which accounts for things like packet loss. PCM is encoded into Opus client-side. At least in Discord.NET, you can send a pre-encoded Opus stream (which I tried, and the resulting files are much smaller), but you won't get the benefits of encoding it at runtime (discord-net/Discord.Net#691). Is that right? I haven't seen a way to transmit audio in any another format in DSharpPlus.

[OoLunar]

At the current moment, DSharpPlus doesn't do any audio conversion. This is set to change in the future. As an alternative you can invoke FFMPEG or use any other audio related lib

[Foxite]

I meant if audio can be sent to discord in a format other than Opus, to reduce bandwidth usage.

[OoLunar]

According to https://discord.com/developers/docs/topics/voice-connections#encrypting-and-sending-voice, it cannot

[Foxite]

If this is a non-fixable limit imposed by discord, this issue can probably be closed as won'tfix, although it may be useful to send a log message when the voice rate limit is hit, if possible.

[OoLunar]

As I'm currently going over the voice gateway protocol, I'm not seeing anything which tells you about bandwidth or ratelimits (see Voice OpCodes and Voice Websocket Close Event Codes. I can reach out to Discord and see what they say, but the response will very likely be "Not an issue on our end, check your code instead."

Regardless, like with all other VNext issues, I'll leave it open until the rewrite releases. I'm making good progress so I would hope that the release is soon

[OoLunar]

Now that I think about it, isn't the bandwidth ratelimit defined on the channel object itself as DiscordChannel.Bitrate? Could it be that we're exceeding this bitrate which is what leads to this behavior?

[Foxite]

To anyone reading this in the future, this problem disappeared after I made my bot only transmit audio when anyone is connected. You can track this by subscribing to VoiceStateUpdated events; there are UserJoined and UserLeft events, but UserJoined does not work properly (UserLeft does).

Update: problem still happens, but I'm not sure if this is a different problem or it wasn't fixed in the first place.