Closes #53. While nextcord recommends changing the import from "import discord" to "import nextcord" it's not required, and I have not done so here. As far as I can tell they don't plan on removing this alias anytime soon, so I think think should keep it for now in case we need to move back to discord.py or over to pycord.

Incidentally, I've also changed the TinyTag dependency from =1.7.0 to >=1.7.0 to be in line with the other dependencies which all have only a lower bound.

Modified Code so that:

• When the command is !list, the output will have audio title, artist, album in the format title | artist | album
• If the media does not have the specified tags, the filename will be used instead

Screenshots:

• !list command

• !play command

Solves the issue #25

The output of the !list command makes use of markdown in its rendering. On desktop/web and iOS platforms, this markdown is rendered correctly. On Discord Android however, markdown does not look to be rendered, and output looks like the following:

whereas it should look more akin to:

@Cephian has reported the bug to Discord. There's not much we can do on our side unless we modify the output of the command to no longer require markdown.

Unfortunately, looking around, this bug looks to have been known as early as 2019.

Closes #68.

A bot can override the close method of a nextcord.Client in order to run cleanup tasks on client shutdown.

Implementing this function will override nextcord's own Client.close(); the implementation of which is shown here (and explains how nextcord will disconnect from VC's on shutdown): https://github.com/nextcord/nextcord/blob/8d82a0858f8440c2b62f92b8e8e6d79b6873c684/nextcord/client.py#L637-L642

Overriding this function has the benefit of allowing us to run our own code on shutdown, but also means that the original close method linked about doesn't run. I've attempted to run this manually, though this oddly leaves to infinite recursion and strange behaviour.

Ideally we'd also run the original close method. But for now, taking the vc disconnect feature seems to result in the desired behaviour.

This PR also pulls the bot nickname restoration and attachment cleanup tasks into their own helper methods.

We tend to run !list more than once per bust, to do things like get Google Form info, make sure everything looks good, etc. We also run it a lot locally when testing. On a large number of songs there can be significant delay and bandwidth consumption from downloading all of the files. It would be nice to have a feature which allows songs to be "cached" so that runs of !list occurring close in time don't both need to download everything.

Despite my feature proposal being sort of long, this wouldn't actually be all that complicated to code. It just involves a lot of arbitrary choices for which I'd like to make recommendations, and I want to hear what others think before implementing it.

More concrete feature proposal:

• Save file <discord_filename> as <discord_message_id>.<attachment_num>.<discord_fileext>
  • We need <attachment_num> because discord messages can have multiple attachments
  • Discord message ids are universally unique
  • Previously we needed unique file ids per-channel and chose <index>.<discord_filename>
    • Now we need them globally unique, someone could delete a message with an old version of their song and resend it for example
    • Our current choice actually has a bug! Discord seems to accept 255-length filenames which is is the max filename length on most common filesystems (more or less) so we'd need to truncate very long filenames, ruining our claim to perfect archival through filenames anyways
• On each !list:
  1. When scraping channel for files, first check to see if cached version exists in attachments/ (as <message_id>.<file_ext>)
  2. If it doesn't exist, download it
  3. Set the modified time of the file to now
  4. Keep only the max(X, # of songs in current !list) newest files and delete all others, where X is say 50?
  • I previously argued that I was against indiscriminately deleting files in the attachment folder mainly because "delete all files in X directory" is never a piece of code you want to have a bug with. But I think in this case it's warranted.
  • We could also do something like "delete all files older than 24 hours", but I don't like this because then we can't prerun !list at any point during the two weeks and it stays cached
  • We could also do something like "delete the oldest files until total filesize is under a certain amount OR only bust files remain" but unless we're extremely space limited this seems like overkill

Implements #60 mutagen is used instead of TinyTag. There is no unified interface for tag formats in mutagen nor a field indicating type, so filetype detection uses isinstance.

It would be convenient if Busty could automatically generate Google Forms for song voting.

From a bit of research, it seems the standard way to do this is to use Google Apps Script. Google Apps Script code is only run remotely on Google Servers and not locally, however scripts can be created and deployed locally through the REST API.

I plan on adding this feature myself, hopefully starting within the next week or so.

nextcord's put out another alpha release with some bug fixes and new features: https://github.com/nextcord/nextcord/releases/tag/2.0.0a7

We should consider upgrading (and testing that everything still works).

Closes #77.

How it works: Instead of splitting "end the bust" code between command_stop() and play_next_song() depending on whether a song is stopped or just hits the end of the playlist, it was unified via a function finish_bust().

• If the bust ends because the end of the playlist was reached, then play_next_song() detects that current_channel_content is empty (but not None) and runs finish_bust()
• If the bust ends because !stop was called during a song, then play_next_song() is called because FFmpeg finished playing, but detects that current_channel_content is None (so finish_bust() has already been called) and just returns
• If the bust ends because !stop was called while chillin, we need to detect that !stop was during the asyncio.sleep() statement in play_next_song when we return from sleeping. We can NOT simply check to see if current_channel_content is None, since it's possible that during the sleep time we stopped, started another bust and populated that list again. Then we add a variable current_bust_invocation which counts the total number of busts that have begun, and ensure that the bust counter before and after we sleep are the same (as well as ensuring current_channel_content is not None)

This will solve the issue #19

• I added a variable to store the file name of the current playing audio
• If it matches, change the list format to bold the audio name

Screenshots:

While working on this issue I have found another issue #34

We have the following code for detecting whether an attachment in a Discord message is a song/video:

https://github.com/anoadragon453/busty/blob/15c4bb0d20a2160f75dbb390b8c10757c68bae67/main.py#L214-L217

However, on accidentally running !list on a fairly old channel with a lot of messages/attachment, I got the following stack trace:

 % python ./main.py 
We have logged in as Busty Dev#3334.
Ignoring exception in on_message
Traceback (most recent call last):
  File "/home/user/code/busty/env/lib/python3.10/site-packages/discord/client.py", line 343, in _run_event
    await coro(*args, **kwargs)
  File "/home/user/code/busty/./main.py", line 57, in on_message
    await list(message)
  File "/home/user/code/busty/./main.py", line 197, in list
    channel_media_attachments = await scrape_channel_media(message.channel)
  File "/home/user/code/busty/./main.py", line 232, in scrape_channel_media
    not attachment.content_type.startswith("audio")
AttributeError: 'NoneType' object has no attribute 'startswith'

It turns out that Attachment.content_type can be None, according to discord.py's documentation. Since it's new in discord.py v1.7, my hunch is that Discord only started recording and returning the media type of attachments recently, and thus this field is None when querying older message attachments.

This doesn't really affect Busty's at all, as we're always dealing with newly uploaded media files, but it'd be good hygiene to handle, especially if my hunch is wrong.

Busty crashes on /info if get_song_length() returns None (which it can). Instead, we should treat that song's length as zero and report that statistics may be inaccurate due to errors.

To deal with the unlikely but possible case that ALL songs have errors, we introduce a "phantom submitter" which is the bot member herself, with a total submission length of zero.

Once #150 merges, we should add a field which shows up in the /info command during a bust, which sends a Discord timestamp to the ending time of the bust.

Thanks to @anoadragon453 for the idea.

While it's admittedly unlikely we'll ever have a single busty instance being used by two servers at a time, I think this a worthwhile upgrade mainly so that we can actually test production busty after updating the server.

I believe the main two things that need to be done for this are

1. Turn global saved image into map guild -> saved image
2. Turn global attachments directory into map guild -> attachments dir

Users can be caught out when they attach their album artwork to a song and submit it, only to find that it doesn't display during a bust. We know of at least one case where this is expected to happen, but is non-obvious: if cover artwork of over 8MB in size in included in a song's metadata, the artwork will be ignored.

When a user submits a song to a bust, we should check for potential, known problems and send the user a secret message with details of the issues if we detect any.

Obviously if the bot is down and there are errors then users will assume everything is fine and we sad when it's not. All I think we can do there is either:

1. Educate folks that if the bot is down (which they can see in the sidebar) then submission checking is offline.
2. Put a :heavy_check_mark: on submissions or some sort of other visual indicator that a post has been submitted.
   • This has potential implications which Jack raised earlier, in that users may assume that submissions cannot be revoked in this case, even if they delete the message.
3. Do nothing about it as the bot is usually up anyways.

Currently I'm partial to 3.

Assuming #143 is implemented and we have support for slash commands, it would be nice to have a /preview command that everyone could use. One would use /preview to submit an audio file and submission text to the busty bot, and the bot would respond with a message that only you can read that shows what your submission will look like when it plays live during a bust.

Most importantly, users can check that their album art will be read correctly and that it looks as they expect. When they are happy with their submission, they submit their track by uploading it to busty's mailbox just as they have always done.

Proposed command syntax:

/preview audio:<audio file> <text>

an example:

/preview audio:<audio file> This is a song I made with my main man @qbert. What a crazy fellow he is. Vocal help from @J. Colle.

Discord should pop up a prompt to select a file from your OS for the audio file. I'm hoping it can do so automatically and users won't need to type/select audio manually.

Additionally, once #145 is implemented, it'd be nice to include those checks in the output of this command as well.