Avoid destroying queue when playing a song

[etyarews]

Description

I happened to accidentally tap on a song while listening to a shuffled playlist, this deleted the queue and started playin the song I tapped.

Problem solved

No response

Other implementations

I think some other players make the tap trigger a small menu with options when there's something else being played

Benefit

Would prevent accidentally screwing up with the queue

Duplicates

• [X] I have checked this feature request for duplicates.
• [X] I have checked that this feature is not implemented in the lastest version.
• [X] I have checked the Why Are These Features Missing? page.
• [X] I agree to the Contribution Guidelines.

[OxygenCobalt]

I severely dislike the friction that a menu introduces, especially if you're just aimlessly playing songs to find one you want to listen to. This would be better as a heuristic or settings option, but honestly I don't really have an idea of how I'd structure that. Leaving this open until I can come up with something reasonable.

[etyarews]

Yes, it does introduce a level of friction, but it prevents a destructive action to happen accidentally. I try not to use Auxio while it plays music in the background out of fear it will nuke my queue, that isn't really nice.

[OxygenCobalt]

The thing is I need to be concerned over how this effects everyone's use @etyarews. Vinyl had a huge thing a few months back over a similar menu being added, since most people don't necessarily mind their queue being destroyed when playing a song.

I have a few ideas of what I could do here:

• I could add some kind of "queueing" mode that's either dynamic or settings-controlled. Playing a song becomes equivalent to "Play next".
• If #407 is added, playing a song could spin up a new playback state. This would probably be a setting normally, since if enabled by default it would lead to a lot of dead playback states lying around.
• I could add a menu, but not have enabled by default. A new setting is added to control whether you want to destroy the queue, add to the queue, or ask every time.

Since all these require some kind of setting, I'd need to be careful to manage it gracefully. The more settings I add, the closer I get to Poweramp's labyrinthine settings menu, which I really don't want.

Tell me what you think of these.

[etyarews]

I'm more of a fan of the first option, in fact, I was already thinking about bringing up the idea of making the randomized queue infinite and dynamic, so it could work better with my #470 request.

My intention was always to eventually ask so that favorite/stared/liked songs to be allowed to appear more likely than once in the queue. If the list is dynamic, then it would sort of "fix" a few paper cuts I have with the way randomized queue works.

However, a much easier solution for you would be to show the #454 menu whenever the user taps on a song when there's a queue being played. But, in this instance, add a switch that asks the user if they want to open the menu when there's an active queue. You could even add a shortcut that opens the settings page, by adding a vertical divider, like it is with some Android's settings

[OxygenCobalt]

I'm more of a fan of the first option, in fact, I was already thinking about bringing up the idea of making the randomized queue infinite and dynamic, so it could work better with my https://github.com/OxygenCobalt/Auxio/issues/470 request.

That's interesting. An infinite queue is a bit of a technical nightmare though to be honest, especially considering how gapless playback would work with it (ExoPlayer expects finite queues, so I could need to do some some very risky rolling-window type calculations to make it work). It's honestly not something I'm really wanting to do.

Honestly, unless more people start complaining about this, this will remain in limbo for now. I am gravitating to a menu though.

[etyarews]

I don't think nuking the queue by default is a good design decision, but I can see why users would be annoyed by having the menu at all. So I think the only solution is to have the menu by default and allow users to disable it right there.

[OxygenCobalt]

Okay, thanks for the feedback. I'll wait and see how other people will respond to this before coming to a conclusion.

[Tom4tot]

https://github.com/OxygenCobalt/Auxio/issues/532#issuecomment-1670477054

Thank you for welcoming feedback. Personally I'm extremely picky when it comes to music players, and it's been a permanent quest to find the perfect one on Android. Until recently I've been using Musicolet which I love mostly thanks to its queue management which is absolutely amazing and addicting, really hard to go back to something else. If you don't know about it, it's basically like you described it here (n°2) and here. It's really useful when switching in between moods or artists/albums. Imagine you're discovering a new album but you have to play different music because you're with people, e.g. at a party or in your car. It's really frustrating and slow to then go back to album, pick the right song, etc. Also, if you're playing a playlist and someone takes your phone and picks another song, you don't have to be worried about losing the current state of the previous playlist. Another use case: you have a big playlist and you want to avoid listening to the same songs until you've reached the end of it. It's really easy with queues saving.

Off-topic: Anyway, that's the only feature I'm missing (as well as a sleep timer but I read you're not interested in adding such a feature, and I understand), otherwise it's really an amazing player you made. It has great UI (including Material You), just enough customization, it's lightweight and of course it's open source. It manages multi tags (and tags in general) really well.

Oh yes, also, another welcomed addition would be that you could sort artists by "ALBUMARTIST" instead of simply "ARTIST". This way you avoid having a ton of artists with single songs that are from compilations.

Anyway, I appreciate your work so thank you again!

[OxygenCobalt]

Thanks for that @Tom4tot. Does Musicolet have some mechanism of pruning "dead" playback states? I think in normal use by someone else unaware of the feature might result in these states piling up and taking up excessive amounts of space.

[Tom4tot]

Does Musicolet have some mechanism of pruning "dead" playback states? I think in normal use by someone else unaware of the feature might result in these states piling up and taking up excessive amounts of space.

AFAIK, no. It has happened to me to have 10+ queues. It's a bit of work to keep them organized but it's completely worth it for me. But it's true your project would become a more advanced player, I could understand that's not what you want. What you can do with Musicolet is that you can easily delete all queues but the one playing, so even if it adds up it's really quick to remove them all. For Auxio you could always make the app remove queues that haven't been played in the last 7 days, or dynamically remove queues when you reach 10 queues, e.g. the first queue will be deleted once there's an 11th one created. I assume a setting for that would be "needed" if you don't want to read too many complaints :D

[OxygenCobalt]

Okay, I'll consider that when working on this.

[n6id]

I could add some kind of "queueing" mode that's either dynamic or settings-controlled. Playing a song becomes equivalent to "Play next".

i would adore this personally.
DSub has something similar (tap-to-queue instead of play, as a setting) and while i did not stick with that app at all, its something that really stuck with me as an amazing quality-of-life feature.
another option that would work for my use case could be slide-to-queue, similar to spotify, but i suppose perhaps thats a little off-topic here, since that way you could still destroy the queue. but it would also not require any additional settings :)

[OxygenCobalt]

Thanks for the feedback @single-effect-event.

another option that would work for my use case could be slide-to-queue, similar to spotify, but i suppose perhaps thats a little off-topic here, since that way you could still destroy the queue. but it would also not require any additional settings :)

I've rejected this prior since it's a violation of design principles, sadly. It also won't work on the home view where you can slide in multiple directions.

[lineinthesand]

I very much second the request to have an (optional) dialog implemented that prevents accidentally nuking the current playlist. The option to enqueue what would otherwise make up the new playlist could also be presented in such a dialog, e.g.:

Replace current playlist Add songs to playlist Cancel

Great player, btw.; it even supports gapless playback!