- It is impossible to edit a playlist while listening to it (or it was until recently).
- Webradios need to be treated a bit differently than song files without putting logic in the client.
- Video support is not planned. See the Why video support paragraph for more explainations
Therefore, the natural thing to do would have been to send patches to either team, adding the features we wanted.
Contributors tend to add missing features on the client side, which seems a bit contradictory with the overall philosophy of a media player daemon. Features added on the client side are only available in a single client software and cannot be shared across different hosts. That fact shows that the daemon should be easier to extend.
How do you want to spend your time
On one hand, you can focus on performance. On the other hand, you can focus on code readability, community code capitalization and features. We chose the latter, which perfectly fits our business case as we run DeejayD on far too fast machines. Other projects fit other use cases, and we reckon DeejayD would certainly not be usable on a NSLU2 or similar devices.
Python gives us code readability. Object-oriented Python gives us easily added and easily managed features. Gstreamer and PyGST, Twisted, Mutagen, Xine and others let us capitalize on community code.
We didn't find it worth debugging mallocs and MP3 playback, and didn't have time to do so.
Python should be fast. Multimedia stream decoding is written in C thanks to Gstreamer or Xine. So we are fine with performance. The memory footprint of the daemon should be bigger than the other solutions's though. But we are fine with that, for now.
Why video support?
We simply find ourselves doing a lot :
user@laptop$ ssh mediaserver user@mediaserver$ mplayer -display :0.0 /movies/movie.avi
A daemon which handles the details of remembering the movie's path is great for this use case.