Writing a music player demon
by rullzer on Nov.12, 2008, under Hardware, Linux
Yesterday Sander and I released a new version of QtMPC (0.4.1).
However when thinking about some of the features we would like to have in QtMPC we once again got annoyed by the MPD protocol. One of the main issues we had was that it is not event based, or even publish-subscribe. You have to ask for every little detail you want. This is a choice and it is true that this way you do not get unwanted messages thus generate unwanted network traffic.
But we feel that some sort of event based protocol will do a better job here. Lets say in the default nothing is send as well. That way mobile clients can still control the player without receiving anything unwanted. Or just subscribe to events related to playback. This way mobile clients are still supported but again. They do not have to request the status ever x seconds. They just get a message once had changed.
For full blown clients event bases is also a positive thing. For example the reaction time. When adding a new song. Right now this has to be noted by the client when requesting the version of the playlist. A simple message from the server saying playlist current newsong …….. (or something like that) could be send right after the song is actually added. It just makes things easier.
Another thing that kind of bother us that there was no inotify support. This would be great however. Lets say you have a music server running on your server. And add some new music to the collection. It would be best of course if it would find the new music. Add it to the database and notify the clients of a change in the music library.
Now we have not written any code yet. But we are thinking about it. For the music playback part we are planing to use gstreamer. Since well it already supports a lot of audio formats. And why reinvent the wheel right?
November 12th, 2008 on 5:59 pm
I can certainly try to motivate you. MPD, although the best in its kind, lacks a lot of features. All developers want to go in a different direction, and the net result is that no new features are added over time. The removal of playlist queues was the reason for me to leave MPD (now I’m not listening to anything, btw, but still :P). $0.02 of advice: set yourself some clear goals, or else you’ll end up just like MPD (except that yours would be event based).
November 12th, 2008 on 10:21 pm
did you have a look at xmms2? its really neat
November 13th, 2008 on 2:01 am
I have added protocol events to MPD several weeks ago, by the way. It’s included in the 0.14 alpha version.
November 13th, 2008 on 2:04 am
Yeah, sounds like a great idea. Another music server to get ignored. I haven’t seen any patches come this way to get functionality fixed, though some of what you mention, inotify at least, would probably be more then welcome if cleanly and well done. And if rejection was a concern there’s the mpd-dev mailing list, but haven’t seen you or Sanders there. MPD is being developed by a motivated developer at the moment too. Not to mention, you could try to re-reinvent this wheel, but there’s a reason MPD has so many clients, it’s because everyone, at least in the beginning, tried to overthink what the music server was doing. So, ya’ll do what you want, but I encourage ya’ll to become more involved in the MPD community and at least /submit/ a feature request for what is desired in the server *sigh*.
And to those who complain about playlist queues, it’s been a hot topic, which will get will probably be dealt with in the long run, but these things take time to do correctly, and it’s not getting any easier people complaining who don’t submit code. Energy is obviously so much better wasted by finding a blog to complain about things.
November 13th, 2008 on 2:08 am
libnotify: mpd now has the idle protocol
Apart from that: It would be more constructive to leave a note on the bugtracker or get in touch with Cirrus (Max) in #mpd on freenode. This way things can progress faster and you can make your voice heard instead of talking to yourself
November 13th, 2008 on 10:23 am
The reason why I just blogged about it here instead of submitting things to the bug tracker is that some of my idea’s are “What MPD is not”:
* An inotify client
* An album art protocol
* A text parser for your playlist files
And I could come up with some more things. But these are things I would like to see. But since they are all here it does not seem wise to sumbit requests like that to the bugtracker, right?
Other than that. I once looked at the code. And while I don’t mind getting familiar with it, but there is almost no comment in the code. But OK, I will drop by on IRC and tell you about some ideas I have….
November 13th, 2008 on 4:41 pm
Fair enough. Have added a notice to the top of What MPD is and is not stating that it is not “rock solid” but “strongly held feelings”. They’re all arguable, but the argument will usually need to be backed up with code.
Why would you want a text parser for playlist files in MPD? If anything that could maybe be part of libmpdclient, but it makes no sense to turn the server in to that.
Anyhow, for further arguments I would think we should definitely argue the merits on a case-by-case basis on the mpd-dev mailing list. Hope to see you there soon.