I’m an enthusiastic noob with Mopidy running on two Raspberry Pi Musiboxes in two different sides of my house. There have been a few times when I’ve wanted to switch ongoing playback from one of the musicboxes to another if a party is generally moving from one part of the house to another. I can do this by just stopping playback on one and setting up the same playlist on another, but I was wondering if there might be a more elegant solution.
From reading the forum it seems as though I should be able to create a simple app or script on my android phone or laptop that queries one musicbox about what its current position in a track and playlist, then issues a command to stop, then sets the same track and playlist up on another musicbox and issues a command to play using JSON commands over http.
The problem is that I have absolutely no idea how I’d begin to start experimenting with this. I’ve installed the mopidy-api-explorer extension on one of the musicboxes but I have no idea how to begin working with it. Can anyone give me a sense of what tools and skills I’d need to start learning in order to take the first steps on this project?
Sounds like a fun project and a useful one. You could write a simple webclient to do this. You’d install it on one (or both musicboxes) and write some javascript to talk to the Mopidy instances. There are lots of existing webclients out there so lots of examples. And you could easily use it on both your laptop and phone. The Web API explorer and Mopidy documentation is the best place to start. If you wanted to extend the musicbox-webclient with this feature I’d be very happy to include it.
Alternatively write a shell script that uses mpc to talk to Mopidy’s MPD frontend. You could only use this on your laptop. It might be easier to get going but probably less easy to actually use.
You could also exend your project to automatically discover the other instances of Mopidy running on your network.They will be advertising their existance using avahi/zeroconf.
Note that pimusicbox is based on Mopidy v1.x so be sure to select that version when using the online documentation.
Thanks! I’ll get cracking on building an extension with this sort of “handoff” capability based on the musicbox-webclient.
I really like this suggestion, and I’d love to incorporate it into my work on this project from the start. I’m still familiarizing myself with the inner workings of mopidy, its extensions and API, so I apologize if this is an obvious question: How would a webclient extension be able to determine whether the server had detected other instances of mopidy advertised on the network via avahi/zeroconf? Would I need to create a backend as well that somehow reported the names of any peer mopidy instances it detects and made those names available to the core and frontend extensions?
Mopidy uses zeroconf to send advertisement messages over the network that other programs can listen for. It doesn’t currently listen for these messages itself so it has no ability to detect other instances (or core API support for communication such information). You would need to write some code utilising zeroconf to do the listening yourself. IMO the benefits of writing this as a new Mopidy Frontend extension are limited to reusing an existing web server for hosting the user interface. It doesn’t make sense as a Backend; aside from the fact Backends are primarily media providers, they don’t have access to Core.
I was envisioning a Frontend extension that used zeroconf to track the advertisements and maintain state about what was around. And maybe some functionality to migrate the playback (although that’s so trivial maybe it doesn’t need that). All of this could be exposed for Mopidy webclients to use. Perhaps take a look at Mopidy-Mopify’s QueueManagerFrontend which creates a websocket for exposing some extra functionality.
Some of this just random ideas, I’m not saying this is the only/best way!