Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Toggle-able mode for the Play command to search on YouTube and SoundCloud instead of picking the best result through YT alone #1022

Open
4 tasks done
kathelynn opened this issue Nov 5, 2021 · 0 comments

Comments

@kathelynn
Copy link

kathelynn commented Nov 5, 2021

Is your feature request related to a problem? Please describe.

AFAIK, #305 issue and #885 issue renders the bot seem unusable when YouTube can't return anything because the bot is designed to rely on YouTube with the default play command especially since people are mostly accustomed to this practice when using a Discord music bot. It is also less efficient when trying to look through both sources, and users are more likely to grab the wrong video or song especially when song covers are involved.

What is your ideal solution to the problem?

The solution would be to give bot owners the ability to "merge search and scsearch functionality into the play command," through the bot config. When this is enabled, the play command would give options between both sources (and other potential future sources) in which users can pick between.

Pros and Cons

Pros

  • This allows bot owners to force users to use multiple sources rather than YouTube by default.
  • Forces users to accurately pick the right song with multiple options before joining the channel and adding the song itself.
  • Doesn't tuck away the SoundCloud source by default in a command nobody is usually aware of (unless intentional for some reason, would love a comment on this).
  • Users can use search and scsearch to filter results to either of the sources.
  • Since this is disabled by default when this is implemented, bots will be off by default.

Cons

  • The quality of the play command is affected since populating the list of results depends on the search term and the quality of the search algorithms of the sources, especially since it is required that more items should be involved.
  • Depending on the approach, people are more likely to prefer a YouTube result, making it less likely to help solve the [Youtube Issue] Error when loading from YouTube (429/captcha form) #305 issue.
  • It is slightly more difficult to pick the best result, especially since two sources are involved and there are no proper comparisons for sorting the songs properly by relevance.
  • Some confusion for both play and search commands.

My own suggestions based on the above

It may be preferable to keep a single list of items, rather than categorizing them by source.
To keep users from focusing on the YouTube list (when separated by source), the sources should be on a single list. The sources can be identifiable (as of now) with the following emojis: ▶️ and 🎵☁️ (or ☁️ alone for the sake of simplicity).

It may also be preferable to sort the list with its own "relevance" algorithms when a single item list is involved
The said algorithm should decide which is the best result for the user based on the information given by the sources. While I do assume that there is a certain line to be able to compare items from both sources fairly, the algorithm does not need to be overly complex if this feature is intended to be disabled by default. That being said, YouTube should be at the top of the list often due to YouTube's more accurate results.

When YouTube doesn't return back information due to 429/captcha, only return SoundCloud and a notice
The bot should still return results regardless, but may only have fewer items in the list and give a notice such as:
Search results may be affected due to an error. If it persists, contact the bot owner.

The search command may be too confusing as the command itself does not refer to YouTube
Just as how SoundCloud search is named scsearch, YouTube search should be named ytsearch while search should be an alias. How this works can be entirely a debate on its own.

How would this feature be used?

  1. For changes to take effect, the bot owner should enable "merge search and scsearch functionality into the play command."
  2. When a user joins a voice channel and uses the play command, the play command should return search results rather than play a song instantly. It should give search results from both sources.

Additional Info

Intending to change the bot identity?

Since the bot was designed to primarily play music from the YouTube source, play and search function the way they are as they are supposed to. This change may be massive as I do understand that YouTube is mostly the main identity of this bot. For this case, I strongly suggested that it should be a "mode" rather than the default of the bot. The bot owners themselves are free to do whatever they need to do for their own environment. To some extent, it may change what seems to be the scope of this project, which may be well enough to decline this feature request on its own.

What's the purpose?

The purpose is to show that the bot is capable of searching for items other than just YouTube alone. Note that in some cases, YouTube is less likely to be considered a music streaming platform in comparison to Spotify and Apple Music. SoundCloud is particularly useful in some cases and can be an okay workaround. It may also pave the way for the potential support of other sources. In my opinion, just presenting to everyone (rather than relying on bot owners to inform) that "yes, this bot does more than just YouTube alone" may well be enough to make this feature request worth it rather than holding onto a thin line of thread that is called YouTube. While I am capable of working on this on my own, I'd love to see what you guys think of it to take the time to implement this.

Sorry for the long post, but thank you for reading this far

Checklist

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants