Part of the reason for having started mopidy was that we wanted something MPD like, but with Spotify support, which at the time was not reasonable to integrate directly.
Now we've evolved quite a bit since then and are now at a stage where we are modular music server, where the MPD frontend is just one of many possible ways of talking to our server. Additionally everything is an extension, so we don't end up like some other systems I've seen where plugins end being second class citizens.
Edit: Other things to note is that at the time we started, 2009, we were not aware of Tomahawk, and more importantly, we wanted a server, not a GUI app.
Actually tomahawk's logic was based off of playdar[0], which is a "Music content resolver", what mopidy seems to be. I'm not close to the project, but it seems like playdar focused too much on the server and lacked a really good ui. They started from scratch with Tomahawk, and now are based on a UI.
Is it a lot of work to implement? For example, do you already pass a 'stream id' to each command to identify multiple streams, or would that have to be added to everything? And is it something that somebody is working on or that is planned for the near future, or just on some 'nice to have someday' list?
i'm assuming spotify and soundcloud management doesn't really work with the mpd clients does it?
also, i think part of the reason why i moved away from mpd, and towards cmus, was because of things like ape, and library management. i see there is a beets plugin for library management.
what about cue sheet support? how complex, simple, would it be to add cue sheet support?
Do you mean playlist management? The upcomming 0.19 release has a target of fixing that for the MPD frontend, from there the backend authors just need to make sure they implement the right interfaces and this will work.
CUE sheets as in using them as playlists? There are a few ways of doing this depending on what your use case is, but very much doable. Drop by #mopidy on freenode or send us an email and we can help work out the details.
It is unclear to me if tomahawk provides a single frontend or if the frontends are also pluggable. My main use case for mopidy is to allow me to treat Subsonic as if it were a local MPD server instead of using the web interface.
I run Mopidy on a headless raspberry pi to wirelessly play Spotify through my amp. Can use DLNA clients and a web interface to control. Wouldn't be able to do that with Tomahawk.
The downside that I found to Tomahawk was that I could not select individual songs, only play shuffle mode, at least with Spotify (yes, I have a premium account, etc)
I've run both. They solve different, but related problems.
* Tomahawk is a desktop app. It integrates various music sources so you can play from whatever source is available. I can search for whatever and it will look on my local harddisk, on my Synology NAS, on Soundcloud, youtube, etc. It will play from the "best" source, determined by search match accuracy and bitrate.
What's pretty cool is that it is integrated with Echonest (www.echonest.com) so you can define "Radio Stations" based on criteria like artist similarity, song mood, energy, etc. And those songs will be automatically resolved. My experience has been very good, everything works out of the box. Only the youtube resolver needs to be enabled manually (for copyright reasons).
* Mopidy, as far as I know, aims to do this on the server side. I've run an early version, I think 0.18 or something, on my Raspberry Pi. It involves some configuration to get it to work. Also, I don't think it can resolve songs in the way that Tomahawk does it: because MPD seems to have a static concept of the "Library". So you can import your Soundcloud "Liked songs", and they will be available in your library, but you cannot search for arbitrary songs. At least I didn't find that option.
You can search for arbitrary songs with most extensions and I believe this includes mopidy-soundcloud. You must have used something much older than v0.18 as it was released about a month ago and needs no more configuration than any other media player i.e. where's the music. Finding a an MPD client that works how you want is the tricky bit.
I'm also not completely familiar with tomahawk, although I have read quite a bit about it.
Tomahawk is a UI that has a standard "music player" behaviour. The sources are plugged in (they're called resolvers[0]), so that the core remains more or less the same.
AFAIU, mopidy acts a middle-man between sources (installed as plugins) and uis. It's more or less what playdar [1] (the ancestor of tomahawk) was, at least functionnally.
Looks like I have a new weekend project. If the dev or someone who has used this heavily is lurking here:
I couldn't find this in the documentation but is it possible to setup multiple local sources? Would I just setup mopidy on all of those computers? Is there a way to stream them into a single library so I don't have to connect to all of the sources every time I change clients?
Mopidy is a fantastic piece of software. I once wrote a Node.js server to provide a public web interface to a single shared playlist, put it on a Pi, and hooked it up to an amplifier.
Very cool. This has been on my sparklist[1] for quite a while. I'll be installing on a Pi tonight, but from the documentations it looks very well executed. Awesome work!
Curious. Does anyone know whenever it plays only locally or can stream it further (like to a desktop computer or phone)?
If so, it could be plain awesome. I'm imagining a server in closet that aggregates music collections from various sources and provides uniform interface to play it anywhere network-accessible.
The use case that I'd be really excited about -- and something that I have been strongly considering hacking MPD to do -- would not be an icecast stream to my phone, but for my phone to have its own Mopidy or MPD instance.
Right now, at work, I simply NFS mount my home music library, and then sync my mpd tag cache over periodically. This works while I'm in one location, at work, but would not work on my cell phone; I don't have a network protocol that would survive it, and MPD has no real support for high-latency filesystems (it doesn't know to go fetching the next file in advance, nor does it know to go cache a few megabytes -- or the next few songs -- in case the data link goes away).
Mopidy's extension support is pretty exciting, then! It seems like it should be relatively possible to concoct a 'mopidy.remote' extension that knows how to do these things, and the corresponding server-side for a Mopidy instance running at home.
Have you folks thought of this sort of use case? Am I about to reinvent the wheel?
yes, you can access it remotely. mopidy is an MPD server, so any platform that has a compatible MPD client should be able to access it. The docs list a lot of the available clients and their compatibility with mopidy:
This idea keeps coming up and I believe mopidy is perfect for building such a system (of course I am biased as one of the main contributors).
The way to go about building this with mopidy is essentially one of the following:
- Create the voting system based on the MPD protocol to talk to mopidy
- Create the voting system using our JSON-RPC websocket access to the core APIs.
- Create a frontend in python with full access to the core APIs.
Each of these of course have it's advantages and disadvantages. But to me one of our main strengths is the architecture we've designed over time and how people can use mopidy almost like a framework for exposing the media server in a novel way.
A web based audio/video streaming application and file manager allowing you to access your music & videos from anywhere, using almost any internet enabled device.
Let's see where it all leads!
[0] http://www.tomahawk-player.org/.