Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
It appears, minidlna's functions fall into three major groups:
Continuing (re)indexing of the media-files collection.
Talking DLNA-protocol to clients.
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.
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.