I like mpd. I like Mopidy. It would be really nice to use them together – Mopidy doesn’t support all of the media formats supported by mpd, and it would be a little bit unreasonable to expect it to.
Obviously I could just use the same client to connect to both, but I’m interested in having playlists that contain tracks from multiple sources. I don’t see any particular reason why it shouldn’t be feasible to build an mpd client extension for Mopidy. (After all, it already supports Beets, although it doesn’t use the mpd protocol to do so.)
It seems like a surprising thing to not already exist. Is there some particular issue that prevents this from being workable? Am I just missing an existing project/configuration in my search? If not, I think I may try my hand at implementing it myself.
What media formats are you looking to work with that aren’t supported by Mopidy? Do you know where the incompatibility lies? It could just be that you don’t have the appropriate gstreamer codecs installed.
I’m not entirely sure what the incompatibility is. I was going to list off a whole bunch of formats, but it turns out that all of them are in gst-plugins-bad. But I have gst-plugins-bad installed, and they still don’t work in Mopidy, but they work in mpd.
The formats backed by gme are the ones in particular that I was trying to use.
gme is also known as game-music-emu, and it’s a player library for a number of different video game emulation-based music formats. It’s kind of on the outdated side and many of the formats it supports are better supported by other tools, but it’s the only one supported by either gstreamer or mpd. (It’s looking for a new maintainer… it’s tempting to take up that mantle.)
I don’t have any logs at the moment but I can see about generating some later, since I didn’t realize I had stumbled across a bug.
However, even fixing whatever’s wrong with it in Mopidy wouldn’t really satisfy what I was wanting to do, because… well, I’ve got ambitions. I want to build a player for a whole bunch of formats that aren’t currently supported by much of anything (I wrote the only extant players for some of them), and I really don’t want to build gstreamer plugins.
For that project, I’m considering a couple of different implementations, but the leading contender in my mind right now is building that project to be a self-contained mpd server. But however I build the backend, I’d want to be able to expose it through the mpd protocol in order to give users their choice of player frontend. And then to unify my libraries together, writing an mpd bridge for Mopidy looks like it’d be straightforward and it might be useful for other cases than just mine – I can imagine using Mopidy in that context as a proxy to unify libraries that aren’t all on the same computer.
If you’re still unable to get it all to work, instead of trying to get Mopidy to puppet mpd, have you considered a transcoding approach? You could try building a program that transcodes these formats on the fly, and then create a Mopidy extension to support this.
I’m just not sure how puppeting mpd could work, given mpd plays its own audio but Mopidy needs it routed through gstreamer.
I managed to get the gstreamer plugin working on my Pop!OS machine but I’m not quite sure what I’m missing on my Gentoo system, and that’s where I’m running the server. That’s not a support request at this point, and it’s kind of beside the point – gme is ancient and hasn’t really been maintained in years, and it still doesn’t support all of the formats I was planning to use.
A transcoding plugin is something I’d considered, but I’m mildly concerned about library management, since as I mentioned some of these formats don’t have a 1:1 relationship between files and tracks – a single file may contain multiple songs, or a song might have the sequence data and the sample data in separate files, or the metadata may be stored externally. And if I’ve got to manage all of this anyway, it seems like I’m basically most of the way to reimplementing the whole thing, and I might as well abstract the whole thing away in a way that isn’t tightly coupled with Mopidy’s plugin architecture. (And if I can then build the Mopidy plugin in a generic way that isn’t coupled to my backend, bonus!)
As for proxying mpd, it has a lot of options for audio output. It can output to a fifo, or to JACK, or to an http stream, or to a Shoutcast server, or it can launch a process and write the audio to its stdin, or you can use PulseAudio and set up a virtual sink… JACK or PulseAudio would probably be the best choice, since they both have standard gstreamer source plugins.