Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


Off-loading file-serving to Apache

  • It appears, minidlna's functions fall into three major groups:

    1. Continuing (re)indexing of the media-files collection.

    2. Talking DLNA-protocol to clients.

    3. Serving the actual media-files to clients - via HTTP.

    I think, if the last function could be "outsourced" to a stock web-server - such as Apache - developing other parts could speed up. No more dealing with the sendfile() intricacies and other compatibility issues… You will also gain the security features of such a framework (for example, Apache typically runs as a non-privileged user), etc.

    Also, adding on-the-fly transcoding may be made easier - Apache's framework makes it easy to run CGI-scripts as well as pass them parameters (such as the optimal encoding for each of the players).

    Even the second part - speaking DLNA to clients - can be handled by a web-server, if the relevant pieces of minidlna are turned into a web-server module. (mod_minidlna, perhaps?)

    The minidlna executable itself can then concentrate just on (re)indexing and - unless automatic reindexing ("inotify"-prompted) is requested - need not even be running as a daemon.

    It does not have to be Apache, but most devices running minidlna have a web-server as well (if only for management)…

    I'm sure, such re-engineering will be a substantial undertaking, but - it seems to me - the gains will be well worth it.

  • Justin Maggard
    Justin Maggard

    Well, it was designed with the intent of having the ability to run on low-power systems.  Even today, it's used on some very small embedded devices; and for those systems it's very important to use as little flash space and memory as possible, so Apache is out of the question.  We really can't avoid running as a daemon either, since MiniDLNA also has the task of sending and responding to SSDP discovery packets.