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

[Audio] Autoplay failure with User scope playlist #6281

Open
aikaterna opened this issue Dec 29, 2023 · 3 comments
Open

[Audio] Autoplay failure with User scope playlist #6281

aikaterna opened this issue Dec 29, 2023 · 3 comments
Labels
Category: Cogs - Audio This is related to the Audio cog. Status: PRs Welcome No one is currently assigned to this issue, but we'd be grateful if anyone made a PR. Type: Bug Unexpected behavior, result, or exception. In case of PRs, it is a fix for the foregoing.

Comments

@aikaterna
Copy link
Member

aikaterna commented Dec 29, 2023

What Red version are you using?

3.5.5

Cog name

Audio

Command name

autoplay

What did you expect to happen?

I expected a Red playlist saved with the User scope would be able to be used as an autoplay playlist.

What actually happened?

A User scoped playlist, set in [p]audioset autoplay playlist, is never started on bot start nor does [p]autoplay queue a song from that playlist.

In running in verbose mode, this traceback is offered on bot start or while using [p]autoplay.

VERBOSE [red.cogs.Audio.api.AudioAPIInterface] Failed to fetch playlist for autoplay
Traceback (most recent call last) 
/Users/aikaterna/red38/lib/python3.8/site-packages/redbot/cogs/audio/apis/interface.py:938 in autoplay
❱ 938 playlist = await get_playlist(
/Users/aikaterna/red38/lib/python3.8/site-packages/redbot/cogs/audio/apis/playlist_interface.py:392 in get_playlist
❱ 392 raise RuntimeError(f"That playlist does not exist for the following scope: {scope}") 
RuntimeError: That playlist does not exist for the following scope: USERPLAYLIST

User scoped playlists are saved in the SQL db as the user ID as the value in the scope_id column. However, when loading playlists with the get_playlist function, we are passing in the bot's ID instead of the playlist owner's user ID, which causes the lookup to fail on User scoped playlists.

The autoplaylist config value we're looking at to start that get_playlist lookup only offers the playlist ID, so not sure if we should be doing another lookup at that point to fetch the true author instead of assuming it's the bot ID.

How can we reproduce this error?

  1. Have the bot running in verbose debug mode to view the traceback
  2. Set a User scoped playlist as the playlist in [p]audioset autoplay playlist
  3. Use [p]autoplay or set autoplay to start with [p]audioset autoplay toggle and then restart the bot

Anything else?

Additional context:
The fact that user playlists don't work for auto play is intentional - because auto play is a guild level feature meaning guild and global scoped playlists should work for it, but user not so, as we may exposing user data to users in a server that the playlist author/manager is no longer in.
There should be an error show to the user when trying to set a user scoped playlist as an autoplay playlist.

@aikaterna aikaterna added the Type: Bug Unexpected behavior, result, or exception. In case of PRs, it is a fix for the foregoing. label Dec 29, 2023
@github-actions github-actions bot added the Status: Needs Triage This has not been labeled or discussed for handling yet. label Dec 29, 2023
@aikaterna aikaterna added the Category: Cogs - Audio This is related to the Audio cog. label Dec 29, 2023
@Flame442 Flame442 added Status: Accepted We want this and removed Status: Needs Triage This has not been labeled or discussed for handling yet. labels Jan 2, 2024
@sxliang3093
Copy link

Hey! I would love to work on this! Thank you

@sxliang3093
Copy link

I was wondering if the project manager could assign me this issue? Thanks!

@Flame442
Copy link
Member

@sxliang3093, You are free to create a PR for any issue labeled as "Accepted" or "PRs welcome". We don't generally assign people to issues outside of core contributors. When we don't have a great line of communication with a contributor and don't have a PR already created, we don't know if/when they decide to abandon working on the issue. If you create a PR, it will be linked to this issue to make it clear that it is in active development, and we can see the progress towards fixing this issue. Feel free to label your PR as a draft if you have not yet fully resolved this issue.

If you need any additional help contributing, feel free to reach out in our discord support server.

@Flame442 Flame442 added Status: In Progress There's a PR open to deal with this, or an org member is working on this internally and removed Status: Accepted We want this labels Apr 25, 2024
@Flame442 Flame442 added Status: PRs Welcome No one is currently assigned to this issue, but we'd be grateful if anyone made a PR. and removed Status: In Progress There's a PR open to deal with this, or an org member is working on this internally labels May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Cogs - Audio This is related to the Audio cog. Status: PRs Welcome No one is currently assigned to this issue, but we'd be grateful if anyone made a PR. Type: Bug Unexpected behavior, result, or exception. In case of PRs, it is a fix for the foregoing.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants