Open aikaterna opened 2 years ago
This would be resolved automatically with ll 3.7 and by using the REST api.
alternatively the next best solution would be listen for shard ready or ready - then iterate through all players in the given shard/bot and sent a dc op followed by a start op
What Red version are you using?
3.4.18
What were you trying to do?
Keep the bot playing, or in the case of a ws interruption, handle the players appropriately and destroy all of them. I considered opening this issue on the Red-Lavalink repo but I figured since it had to do with a bot event, that I would post it on the main repo and it can be moved if appropriate.
What did you expect to happen?
On an on_ready event I expect the bot to disconnect from channels (expected, and happens), but then I also expect the previously playing players to be cleaned up (does not currently happen).
What actually happened?
Bot is playing music on >= 1 server(s). Bot receives an on_ready event (or other events that register as an on_ready event, not sure if other related events fire off on_ready as well) Bot disconnects from voice channel after a small period of time The Red-Lavalink Player object for each player is still active, but not connected to the voice channel. [p]audiostats will say playing on 0/x servers. Commands like play that queue Tracks into the player still queue with no obvious or obnoxious errors, but the bot will not connect to the channel again without audio being reloaded first.
How can we reproduce this error?
See above. Should still be reproable with a manually invoked on_ready. Also, an example of the code I use to catch this event currently, which lets me know to reload audio sometime:
Anything else?
I am under the impression that this might be resolved by sending the op code listed in this section of the Lavalink implementation: https://github.com/freyacodes/Lavalink/blob/f2c789ee5cf17229e3d98b1a521d22d6bfd0b9fb/IMPLEMENTATION.md#special-notes but I have not tested this theory.