Playlist between MPoD and web interface are not in sync

[futuralogic]

Via the web interface I created a queue of songs to play that I was playing this weekend.

Later, I load MPoD on my iPhone and it shows only 1 song in the playlist (from the web queue).

I use Browse on MPoD and navigate to songs on my NAS and add them to the playlist using "Play only this directory" - which should clear the web queue? and enqueue a new set of tracks. I'm presuming it should behave as it did under 1.55 where MPoD and web queue are the same thing.

MPoD now shows my tracks enqueued (correctly). I start playing - volumio/MPD starts playing.

I open web interface, and the same queue from this weekend is there, except the currently playing track (from MPoD) is at the top of the list. The track name is correct, but the album art is wrong.

The "Playback" tab also displays incorrect information.

See screenshots:

[Screenshot of MPoD playing track...]

[Screenshot of the Queue - Top entry is correct track name + artist, but album art is incorrect. Additionally rest of tracks in queue is my "other queue" which never seemed to get cleared on the web side of things.]

[Screenshot of playback - Correct info, but album art isn't refreshed]

[RastaX]

I noticed the same behaviour on "MPD-Remote"-App on Android. Plus: The Stop-Button in the App works as NextTrack in the Web-Interface.

System: Odroid C2 with HifiShield

[volumio]

The queue is now handled by Volumio instead of mpd. That's why you see only current track in mpd. We plan to emulate mpd queue from volumio, this way you'll see the full queue on mpd clients.

[ceffo]

It would be nice to support both the mpd queue as well as volumio's own interchangeably like it was in RC1. I am pretty sure a lot of volumio users use other mpd clients as well as the web interface. The later is useful for webradios but unfortunately with large music databases, the lack of good search, browsing by album, artists, composers etc, makes it impractical. Thanks for the awesome work though.

Le mer. 29 juin 2016 à 04:19, Volumio notifications@github.com a écrit :

The queue is now handled by Volumio instead of mpd. That's why you see only current track in mpd. We plan to emulate mpd queue from volumio, this way you'll see the full queue on mpd clients.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/volumio/Volumio2/issues/494#issuecomment-229288542, or mute the thread https://github.com/notifications/unsubscribe/AM_tbbE_M5tQHBZPiJAklCIRVmDjf2O5ks5qQiqCgaJpZM4JAsqQ .

[youpilai]

I'm following this with great interest.

I'm used to use mpc commands in CLI, or some python script, to feed/control volumio, and I can't do it anymore due to this lack of sync. Same for the command 'Stop', that work for the current song but Volumio immediately start to play the next song in its playlist I'm using also the Consume, Replaygain and Crossfade modes, so it would be cool if these could be sync too (at least for Consume, the one you can change in the UI)

Anyway, thanks for your great work i'm using every day...

[quantenschaum]

same problem here. In Volumio 1.55 the playlist was handled by mpd, which was great especially when using it as UPnP renderer, because the renderer handles the playlist. Webinterface, mpc, UPnP, all in sync. Now it's a mess, sorry to say this. It's even so, that node and the UPnP interface fight against each other. When I say stop via UPnP, it shortly stops and then starts the node internal playlist again. I switched back to Volumio 1.55.

[Hobby-boy]

I added a cue file in the Volumio interface in 2.001, and the interface stays on the same track all the time (with only the time resetting), but the mpd client has the full contents and the right track of the cue file listed. I believe it might also be related to this issue.

[volumio]

Yes, don't expect the Ui to mirror what MPD is doing. IT'S NOT A BUG, its by design

[quantenschaum]

Well, to be honest, in my opinion this is bad design then (you may have your reasons, but my personal opinion is, that I do not like it). In Volumio 1.55 it was in sync and this was good. MPD handles the state (because it is actually the state of MPD) and the other interfaces like upmpdcli, shairplay, web, ... sync themselves. This gives a nice and consistent experience. MPD in the center, handling playback and a bunch of different interfaces to it. It's not really clear to me, why you are sacrificing this feature?

[youpilai]

For now, i kinda think like quantenschaum. I know Volumio team has done a huge work to achieve the complete rewriting for Volumio 2, and don't want to offense anyone here. When i discover that the queue was now handled by volumio, i was really disappointed, because all my stuff in python to feed the queue didn't work anymore. And for now, the emulation of mpd is not complete. I suppose that you (Volumio) have choose to do that way to have more control on the queue, and so enhance the possibilities of the web UI (implementing stuff like Drag an Drop to reorder the queue maybe ?). And this is good, i'm the first to ask for more capabilities. Still, i noticed another side effect i put on this choice : responsiveness. Volumio 1.55 was very fast to things like "Clear and Play" on an album. Now i sometimes wait like 10 sec to see the queue change and the music playing. I know that for now, the goal is to correct bugs and as it has been said, here we are not talking about a bug, but i hope that in the future we can have a way to control/feed the Volumio queue from outside

[quantenschaum]

Good point @youpilai

And for now, the emulation of mpd is not complete.

Why do you want to emulate mpd, when you have an actual mpd instance running under the hood? I absolutely respect your work and you have done a great job, but this simply does not make sense. Mpd has an interface to query and manipulate the queue and more. Don't reinvent the wheel.

[volumio]

@quantenschaum in fact it makes a lot of sense, here's why:

• We decided to offload the queue managment from mpd because we wanted to be able to put in the queue stuff from mpd, spotify, tidal, streaming services etc. With the current queue mechanism you can handle the queue in a very flexible way. By using the mpd queue you could not have done that.
• Another advantage is being able to search, play and use all the new features (spotify, tidal etc) from any mpd client. So imagine you search something, and your mpd client will see everything that you have on volumio, not only mpd files
• The 2 above require the mpd emulation plugin to be finished, which is currently one of our last priorities. Bear in mind that this emulation is just emulatin the control interface, not mpd by itself.

Hope you guys now have more clear the bigger picture we are working on, and hope this motivates you to help us finishing the mpd emulation interface

[youpilai]

if only i have the skills...

[futuralogic]

Is there documentation on the MPD Emulator that would provide prospective developers a place to start? Any type of interface agreed upon that defines what we're "emulating" and what we are not emulating. Since MPD is running on the device, would the emulator run on another port, or would we want it to use the public mpd port for best compat? Would that mean the default mpd would need to run on a custom port that volumio itself talks to?
Just trying to get a feel for the breadth of the changes required.

[youpilai]

for what i know, you can find the "mpdemulation" plugin in "/volumio/app/plugins/user_interface/mpdemulation" You'll see that only basics needed commands are implemented: IDLE LISTALL NEXT OUTPUTS PAUSE PLAY PLAYLIST PREVIOUS STATS STATUS STOP TAGTYPES

I did try to understand how it works, but my skills in javascript are not good enough

[volumio]

@futuralogic there is no documentation about that. But we can use this thread to exchange infos. I'll try to outline everything needed to achieve our goal here:

• Ideally our plugin for mpd emulation will run on default port 6600, while mpd will run on another. This way we'll have compatibility with every client
• Basically, we need to implement almost every music browsing, playing, status, volume control and search method found in the websocket plugin in mpd. https://github.com/volumio/Volumio2/blob/master/app/plugins/user_interface/websocket/index.js
• This way the mpd emulation will work as a way to control every function of volumio playback from mpd clients (including webradios, spotify etc)

What do you think? Did I explain everything? If you want more info, just let me know

[f0ff886f]

Can you write a bit how the commRouter interface works and where we can find all defined methods? ie:

libFast.bind(self.commRouter.volumioNext, self.commRouter)

It seems that for many methods the commRouter needs to map to MPD commands.

It's quite sad that from volumio we went from an MPD player that can be controlled by MPD clients to Volumio2 no longer supporting MPD clients almost at all, breaking many people's workflow with the tool. Comments such as "that's why we built the webui for you", when it's incredibly slow interacting with versus a native app on any platform bring a little sadface out. Especially knowing it is the last thing on the priority list... I guess that's why we're here, to write what's important to us and contribute code back.

[volumio]

@vostok4 your typical workflow would be:

• Find the command you want to send in the websocket file https://github.com/volumio/Volumio2/blob/master/app/plugins/user_interface/websocket/index.js

Once you found it, replicate it in the mpd emulation plugin https://github.com/volumio/Volumio2/blob/master/app/plugins/user_interface/mpdemulation/index.js

connWebSocket.on('next', function () { var timeStart = Date.now(); self.logStart('Client requests Volumio next') .then(self.commandRouter.volumioNext.bind(self.commandRouter)) .fail(self.pushError.bind(self)) .done(function () { return self.logDone(timeStart); }); });

So, next will become in the mpdemulation

InterfaceMPD.prototype.handleNext = function(sCommand, sParam, client) { var self = this; var timeStart = Date.now(); // send Next command to CommandRouter self.logStart('Client requests Volumio next' ) .then(libFast.bind(self.commRouter.volumioNext, self.commRouter)) .fail(libFast.bind(self.commRouter.pushConsoleMessage, self.commRouter)) .done(function() { return self.logDone(timeStart); });

// Respond with default 'OK'
client.write('OK\n');

};

Hope that helps . If you want to share your progress (your forked repo) I could help you there

[f0ff886f]

Hi @volumio,

It's been a while but I'd like to revisit this. It seems like MPD support hasn't really evolved, and now I should be able to hack a few hours a day.

Could you help refresh my memory with the current expected state? For example, if I play a song via MPD, the web interface will not show any of the currently playing info. Is that expected? If so, I'll start there. Otherwise, there is some other bug plaguing my system.

Is the code https://github.com/volumio/Volumio2/blob/master/app/plugins/user_interface/mpdemulation/index.js still valid in the overall architecture of volumio?

Also, there is a new option in the playback settings, to allow or disallow MPD Volume. Is this to allow / disallow setting of the volume via MPD? Where is this reflected in the source code?

I will be working by editing directly on the RPi and restarting the volumio node server, that should work OK, right?

[f0ff886f]

Also, right now MPD itself still exists on the device, to play music from the actual library. What happens when I want to play a song from the web interface? What is the actual process that plays the MP3, also MPD?

[volumio]

Hi @vostok4, happy that you'll help on this. The rationale of the mpd emulation controller is to "behave" like mpd. So ideally, we will expose the 6600 port with nodejs and change the mpd port that volumio uses. So, for example if you have mpod and you'll add an item to queue, it will go trough the mpdemulation plugin, then to the commandrouter with the addQueueItems function etc...

Let me know when you'll need help

[Xotter]

I have written a script that uses the volumio REST interface and mpd via mpc. The script has to keep track of whether mpd or volumio is in control at any moment. The single command that would allow me to use volumio exclusively is ADD. The script can provide all of the URIs it needs. So if you are trying to decide what to implement first in the mpd emulation, ADD is my vote.

[musyne]

+1 with quantenschaum Breaking compatibility with MPD is a huge bummer. IMO getting the emulation right should be high priority. Volumio looks like the best server/player in the mpd world but now it feels like it's Volumio OR the others.. Phone clients are not in sync, playback controls are broken (mpc stop...), and everyone's scripts stopped working. Just my 2 cents. No offense and thanks for everything that works fine :)

[f0ff886f]

Hi everyone, I just wanted to say that I am not planning on continuing my efforts with the MPD emulation layer. Project visions split too much between Volumio and Volumio2, so I switched to a different platform for my RPi+mpd needs (moode audio).

I can recommend the work wasn't too hard, unfortunately I never got my tiny platform integrated well with a git workflow, but following the guide in this thread and existing code wasn't horrible.

[buzuck]

My 2c on the topic, I may be utterly wrong.

Streaming was maybe a valid argument for ditching the mpd's playlist. However, I just saw that Cantata has a streaming capability, from Soundcloud, and others. Again, I may be wrong, but it seems that it integrates quite well with mpd :

$ mpc playlist
Estas Tonne - Internal Flight (guitar version)
https://api.soundcloud.com/tracks/540823470/stream?client_id=0cb23dce473528973ce74815bd36a334#{"album":"SoundCloud","artist":"A BOOGIE WIT DA HOODIE","genre":"Hip-hop & Rap","service":"soundcloud","time":179,"title":"Look Back At It","year":2018}

[rehajel]

Last comment 2019, before in 2016... is there any update regarding this or at least the priority/timeline?