You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the client is forcefully disconnected from a voice channel (right click -> disconnect), or possibly other mean as well, the disconnect event does not emit. This means there's no way to detect this, streams will just keep trying to play, hilarity ensues.
Whenever the websocket closes with 4014: Disconnected and there's a channel (not sure why there wouldn't be one), it is setting reconnecting = true, therefore not emitting the disconnect event.
What I personally think should happen: When it gets disconnected for any reason that is not an error, it shouldn't even try to reconnect and just fire the disconnect event. Users should be able to decide themselves if they want to reconnect or not. If this behavior needs to stay for some reason, maybe a "reconnect" option for channel.join(), being true by default for backwards compatibility.
The text was updated successfully, but these errors were encountered:
When the client is forcefully disconnected from a voice channel (right click -> disconnect), or possibly other mean as well, the disconnect event does not emit. This means there's no way to detect this, streams will just keep trying to play, hilarity ensues.
Whenever the websocket closes with
4014: Disconnected
and there's a channel (not sure why there wouldn't be one), it is settingreconnecting = true
, therefore not emitting the disconnect event.eris/lib/voice/VoiceConnection.js
Lines 360 to 367 in e43418d
When it eventually tries to reconnect, it's getting stuck here:
eris/lib/voice/VoiceConnection.js
Lines 172 to 174 in e43418d
What I personally think should happen: When it gets disconnected for any reason that is not an error, it shouldn't even try to reconnect and just fire the disconnect event. Users should be able to decide themselves if they want to reconnect or not. If this behavior needs to stay for some reason, maybe a "reconnect" option for channel.join(), being true by default for backwards compatibility.
The text was updated successfully, but these errors were encountered: