This now sort of respects "Awaiting Endpoint..." waiting. I haven't
actually tested out this case since it's hard to get it. However this
new code does work with the regular connection flow.
This is a complete redesign of the old voice code.
A list of major changes is as follows:
* The voice websocket will now automatically reconnect with
exponential back-off just like the regular Client does.
* Removal of the stream player concept.
* Audio now gracefully pauses and resumes when a disconnect is found.
* Introduce a discord.AudioSource concept to abstract streams
* Flatten previous stream player functionality with the
VoiceClient, e.g. player.stop() is now voice_client.stop()
* With the above re-coupling this means you no longer have to
store players anywhere.
* The after function now requires a single parameter, the error,
if any existed. This will typically be None.
A lot of this design is experimental.
This shows the Shard ID in more places, along with a gateway trace and
session ID. Also helps show the RESUME/IDENTIFY/RESUMED/READY flow a
bit more instead of it looking like the connection has zombied out.
This is a breaking change. No longer does Messageable.send have a
filename keyword argument, instead this is all handled through the
discord.File model. To upload many files you must specify a list
of discord.File objects.
There were some dead-locking issues that I suspect were due to the
way the global rate limit was handled. This changes it into a simple
Event that allows multiple coroutines to pass through instead of one
by one.
WeakValueDictionary cleans up too late and brings too little benefit.
Also clean up the state when the first READY is encountered for
AutoShardedClient and when any READY is encountered in regular Client.
This is a breaking change. The original purpose of no_pm has been
mainly a legacy aspect. They came from a time before checks were a
generalised concept and were never removed. A check is the proper way
to do its behaviour.
There is potential that when recreating the Emoji list in the
GUILD_EMOJIS_UPDATE event would just fetch from cache and the element
in cache having an out of date Guild reference. This Guild reference
will be kept alive for longer than it should be.
By always overwriting the Emoji reference, this problem goes away.
The library had a memory leak in the case using the global emoji cache.
When the bot would leave the guild, the Emoji would maintain a strong
reference to the Guild keeping them alive along with the entire state
associated with it.
This should prevent asyncio.CancelledError from being propagated more
and suppressed "Task was destroyed but was pending!" warnings when
doing graceful closes outside of using a KeyboardInterrupt.
To make clean up a bit more robust, also add signal handlers
for POSIX systems.
Hopefully this means when the bot has some lingering object for
whatever reason, the memory doesn't double due to it having a strong
reference to an outdated connection state.
Rapptz
FrostLuma