Consume and playlist visibility

Hi everyone, I’m new to Volumio, I just started looking at Volumio for a solution for an embedded music player for a homebrew jukebox. There are two problems that combined I see as a dealbreaker for my use though, so I was hoping someone could comment. First problem is that there is no consume mode, which my family finds very confusing when trying to use it. Second and more important problem is that MPD does not seem to be aware of the current playlist queue contents, instead it seems to be only visible in Volumio. I have plans to integrate other things into this, possibly other MPD clients, and not having the playlist queue visible in MPD is problematic.

Any comments welcome.

First problem is that there is no consume mode, which my family finds very confusing when trying to use it.

By “consume mode” I assume that you mean that items get removed from the play queue once they have been played? Obviously this doesn’t work if the play queue is set to repeat, so how would you expect the UI to work? Currently there are buttons for repeat/repeat once, shuffle, save playlist, and clear.

Second and more important problem is that MPD does not seem to be aware of the current playlist queue contents, instead it seems to be only visible in Volumio. I have plans to integrate other things into this, possibly other MPD clients, and not having the playlist queue visible in MPD is problematic.

This is part of the way that Volumio is designed - Volumio is in control of the playlist, not MPD. It seems unlikely that such a substantial change to the architecture would happen without a lot of input from the community. Is there a reason that you can’t use the Volumio Websocket API to access the play queue?

My thoughts are that you would want wide compatibility, which would mean to manipulate the queue in MPD so it’s visible and available to all clients instead of just Volumio. I don’t see how keeping the queue in Volumio instead of MPD would provide any real benefit other than less code, but maybe that’s just because I’m new to the project and unfamiliar with the reasons that was done. I do see drawbacks though… Volumio has to duplicate consume and random functionality that already exists in MPD, and it places artificial interoperability limits on other MPD clients. There are a number of MPD clients out there and MPD is well documented… being able to reuse that pool of effort is much easier than having to custom integrate everything using the Volumio API.

Regarding the queue, I would expect that songs would be removed from the queue once played. I don’t want the queue to repeat at all. Clearing the entire queue occasionally is not an acceptable workaround as I don’t expect the queue to ever be empty so there’s no way to clear it without removing entries that are still unplayed.

Is there a way using the API to remove a song from the queue? I could approximate a consume mode by scripting a call to the API to remove the first position or a specific song from the queue when the currently playing title changes.

I don’t see how keeping the queue in Volumio instead of MPD would provide any real benefit other than less code, but maybe that’s just because I’m new to the project and unfamiliar with the reasons that was done.

One important factor is that MPD isn’t the only source of audio for Volumio. Tidal, Qobuz and Spotify all have playlists that need to be visualised and used.

Is there a way using the API to remove a song from the queue? I could approximate a consume mode by scripting a call to the API to remove the first position or a specific song from the queue when the currently playing title changes.

You can do it using the websocket API, but the volumioRemoveQueueItem function isn’t exposed through the REST API, which I imagine you would prefer. It’s something that could be added relatively easily with a pull request though, probably adding an HTTP delete somewhere around here: Volumio2/app/plugins/user_interface/rest_api/index.js at master · volumio/Volumio2 · GitHub

If I could contribute it via a pull request I would. Unfortunately I’m not a programmer. I’ll have to try and figure out the websocket API call.