Implemenent "prio" and "prioid" for tracklist

[leiflm]

It would be nice to see http://www.musicpd.org/doc/protocol/ch03s04.html#command_prio implemented.
The stub is there, but the implementation is missing. Please add the js/http interface for that call too.

For the context: I've written a web interface and middleware to vote for/{browse,search} and add music at parties using ionic/angularjs (https://github.com/leiflm/SimpleMPDVote). Distinguishing it from others is the fact that it doesn't require any authentication.

The middleware is a voting server, since I didn't see the priority calls in the pympd2 bindings. I would really love to ditch that server and use mopidy directly, if it isn't too much of a hassle for you to implement the priority calls (eventually triggering tracklist changed events, I guess).

[adamcik]

So to finally get back to this and just jot down some thoughts I've had on this topic but seemingly never written down. If we want to support this the same way as MPD does we basically have to turn the tracklist into a priority queue.

I've previously considered doing something like this for random mode. The idea would be to have a tuple (prio, random, tracklistposition) for each track. When adding new tracks one would simply assign a random number between the random value of the current song and one. And if prio gets thrown into the mix it would still get those first. (hopefully this makes somewhat sense)

That being said the more interesting thing than a specific implementation idea is what features / use cases we want to support. For instance having a "play now" queue which gets consumed is something I rather like myself. As a last aside, at one point I was even wondering if we could have multiple tracklists as a solution, so a second one which always has consume turned on and gets checked before the main one.

[leiflm]

Intro: We wrote https://github.com/leiflm/SimpleMPDVote some time ago. It lets people on the local network vote-up songs in the playlist or add missing ones to it from the library. It's meant for parties, shared kitchens or bureaus.
The web app is based on the ionic framework and the server uses python bottles to handle requests.

We use an extra list of (votes, song_id) tuples. But, iirc, we could remove a lot of code/save bandwidth, if mopidy supported two features:

• priorities
• playlist deltas

So that is our use case.

[kingosticks]

I believe Mopify would benefit from the "play now" queue style to better mimic the Official Spotify client. dirkgroenen/mopidy-mopify#73

[dirkgroenen]

This thread hasn't been updates for a while, but to share my experience: I've created some kind of hack in Mopify which creates a tracklist based on prio.

If you would ask me know I would suggest that the current TracklistController.set_random method is quite useless when it comes to shuffling through a prio based tracklist. In my case I've created two arrays which contain information about the 'Queued track' and one which contains a snapshot of the other tracks which is used when shuffle is restored.

When a user enables shuffle it checks the length of the Queued tracks and uses that length as a start point for the TracklistController.shuffle method. This means that tracks added to the queue will always stay on their position, no matter if someone changes the current playlist, track or enabled shuffle.

At the moment my implementation feels a bit like a hack, so in my opinion it wouldn't be that bad to bring this idea back to life.

[adamcik]

https://docs.google.com/document/d/15hEZkB0_W33vUD-pKsf-gk3BICDgxsa1FC0H_lMXFUU/edit#heading=h.k18gu9vpir5u has some ideas about the API which we hope will mature into something that can replace the tracklist API.

We hope that we'll end up with two of these queues. The normal queue will be more or less like our existing tracklist, while the priority queue will be like a tracklist with the options locked and consumable enabled and it will always be asked before the normal queue for the next track.

[dirkgroenen]

Just quickly read through the document and it sound quite good. An other point from my previous comment, which I would like to suggest again since apparently you're thinking about rebuilding the queue/tracklist, is the random/shuffle mode.

Is there a reason why we shouldn't remove the random mode and just literally shuffle the tracklist/queue. That would make it way more easy to get an idea about the next track(s) and it makes it easier to manipulate to next track(s).

[adamcik]

Mostly this is just something that was carried over from our roots as trying to implement something that was more or less MPD protocol compliant. But that being said I see a lot of other player have a split between the play order and the display order when in random mode. So I'm a bit unsure about if we can get away with cutting it out.

Though we might be able to return the queue in display order like we do now, but also annotate each item with a playback order.

As for manipulating the next track, what is the use case for this? Echonest radio by any chance, if so https://docs.google.com/document/d/1X6rvB_OQR0EHlgPrqzBZIRpkLeVhbAdoeRSZvx6vH9g/edit might also be of interest if you haven't already come across it.

[dirkgroenen]

As far as my opinion goes that's something you guys should decide. I can understand that removing something like that isn't the best opinion, but when keeping both methods I would definitely think about creating a way where the play order can be read. My relation with Mopidy has never been on a MPD base, so I can't and won't say anything about what is best for that.

Saw something about the dynamic playlists in the previous document, but couldn't find the specific documentation. Haven't read to full document, but it absolutely sounds interesting. I needed something like this when I started developing the Echonest feature for version 1 of Mopify.