[MUSIC] Skip command corrupts currently playing song and queue

[RikiBorders]

Whenever the skip command is used, sometimes the currently playing song is corrupted somehow (more investigation needs to be done). The coroutine for playing the next song in queue is also interrupted, causing new songs to not be played.

[RikiBorders]

Upon further testing it looks like the queue isn't corrupted at all. Code looks fine too. There actually seems to be a big delay between when the next song in the queue is played after a skip. This delay can be really short or really long.

gotta find the bottleneck

[RikiBorders]

Investigated more, the bottleneck is the _get_youtube_videodetails function. When it downloads videos, it blocks other commands from being called.

For example, if you try to play a 54 song playlist, all 54 songs will need to be downloaded before another command can be called (so if you tried to use the .queue command after queueing the 54 song playlist, it will not run).

I'm not sure if this can be fixed using asynchronous means, but I think using multithreading and moving the downloads to a separate thread would be a good potential approach.

[RikiBorders]

Another much simpler approach to multithreading: Put the queue songs into a 'download queue'. We can setup a new download_song coroutine that downloads songs at intervals. I'm not sure about responsiveness or performance implications behind this approach, but its much easier than using multithreading

[RikiBorders]

I went with the coroutine approach and the bot is working as intended. No more freezes, downloads are completed as a part of the coroutines, and you can send commands while playlist songs are being added.

Should probably implement some sort of video limit for inputted playlists since people can troll and queue up enormous playlists.