search

fredi-68 / Ram

ProtOS Discord Bot (Codename: Ram) DISCLAIMER: This repository is a mirror of my local network source control. Information may or may not be inaccurate. Updates only whenever I can be bothered.
0 stars 0 forks source link

Queueing urls to not cache youtube_dl download urls #33

Closed fredi-68 closed 5 years ago

fredi-68 commented 5 years ago

The reason this is a problem is that most streaming services like YouTube and SoundCloud assign each download link some sort of key or token that expires after a few minutes. If the download URL is cached and queued up, the token can expire before the song is downloaded, causing the track to be skipped. There are two possible solutions to this problem a.) Cache the original URLs instead of the direct download. The benefit of this method is a very small overhead, but the problem is that we can't detect if a song will load properly or if it even exists until the song is selected for playing; or b.) Download each track as it is queued and store it locally on the filesystem, then delete the track after it has been played. The upside of this is that we don't have to deal with any third party inconsistencies since we have everything we need to play all songs in the queue locally. The downside is that we have to manage a temporary directory where we store the songs. This directory has to be cleaned out in regular intervals, and we need to make sure we don't have any "dead tracks" lying around in there in case the program crashes. The other problem is that playback quality may suffer during track download, if a new song is queued while one is already playing, due to the network connection doing increased I/O.

The solution to this problem must include researching both these options to figure out which is the best approach.

fredi-68 commented 5 years ago

So I had another look at this and realized that since we need to run the audio files through ffprobe anyways at some point (see issue #4 ) the only good way of handling synchronous sounds would be to download them to the disk completely, then analyze and play from there. So b) it is.

fredi-68 commented 5 years ago

Implemented solution b). Web resources are now downloaded to the _temp/audio folder in the root directory of the bot. The target for the FFMPEG process is changed in such a way that it reads from the local copy instead of the remote resource. After playback has finished, or - if a problem occurred - the object gets garbage collected, the respective file is deleted again. It is important to note that this change only applies to sounds queued using the +play commands youtube_dl integration. All other sounds still use the old FFMPEGSound class for playback, which allows for arbitrary target URIs