Smart queuing like Spotify

[PureTryOut]

Spotify handles queues a bit differently in a way I quite like.
Basically when you're adding a playlist there is an option for any song to "add to queue" in which it adds it as the next song to be played rather than at the very end of the queue. If someone would add another song to the queue like that it would add it after the track added before, but still before the rest of the playlist.

This way you can just play a playlist but still add in random tracks in between without having to mess with the entire ordering of the queue. For this the application needs to keep track of both what tracks in the queue come directly from the original playlist but also what tracks were manually added in between and combine those two in the actually playing queue.

[kingosticks]

MPD provides something similar with a priority for tracklist items. We don't support that part of the protocol but ideally whatever we do here should be flexible enough to solve that case too.

I think there are Mopidy web clients that have provided extra queuing behaviours, maybe like this. I think providing more API tools to do this kind of thing is a good idea but I'd want to be more flexible than just making Spotify's (current) scheme work. They'll change it next week anyway.

[PureTryOut]

Ah good to know. If it internally basically already supports it and just needs API then that sounds good to me! Would it be possible for a client though to show the difference between a track from the playlist and a track manually added to the queue? As far as I know (it's been a while since I looked at the API) there is no indication in a queue/tracklist where the track comes from no?

[kingosticks]

Sorry, if I misrepresented the state, we currently do not support anything like this. We have a single flat queue today. This would all be new. I'm just focusing on making it flexible and normally that falls out from starting with a flexible API.

I think supporting a general multi-priority case might be good. We'd have multiple per-priority queues. For clients wanting to emulate Spotify mode they'd use just two queues. Clients would always have to buy-into using these new APIs, I can't see a way to make it a default Mopidy behaviour and I really wouldn't want to, these 'non-standard' ways change all the time.

And correct, there's only the tracklist id currently, and that's just an incremental number. As you say, we'd have to expose its priority in the tl_track model.