Project:Sound/Mt-daapd maintainers guide

= mt-daapd maintainer's guide =

Introduction
is a daemon that implements the server part of the DAAP protocol, developed by Apple for its iTunes 4.0 player to share the music locally. DAAP is currently supported by, too.

This package also replaces the old  original package, as that stopped working correctly with recent iTunes (5 and 6). It also has better performance and is currently maintained.

The main drawback of  respect to   is that the shared files have to be all on the same filesystem for every daemon running. This can be worked around by using more than one session (see later).

Multiple instances of mt-daapd
As it was said,  requires all the shared music files to be on the same filesystem, as it uses the inode's indexes to cache the music files. As this can be a problem for some users, the recent revisions of  in Portage are able to run multiple instances of the daemon itself.

Setting up a new  instance is simple, and it's like the way multiple network interfaces are configured: just symlink   to. Once that is done, the new  service will look for the configuration file in.

It's important to make sure that the different instances of the daemon should not share the same cache directory or that would break them. The pidfiles are managed by the init script, using a patch applied by the ebuild to  sources (already accepted upstream).

Interaction with mdns responders
has its own implementation of the Bonjour protocol used by iTunes for discover the DAAP shares on the current network (for this reason, Bonjour is one of the fondamental part of a DAAP implementation). It can use either that internal version or an external responder provided by.

Support for  responder should be currently worked on by upstream; in the mean time for people wanting to use that instead of , the ebuild make use of  's compatibility layer with. The howl useflag has a conditioned avahi useflag, when that is enabled, it does depend on  instead of , and then uses the includes and the libraries provided by the first. This compatibility layer issues a few warnings on daemon's output stream when the library is initialized.

As the service have to talk with the responder when started, it has to depend with a need clause on the right responder; being conditioned on the howl useflag (as the internal version does not require an extra service to be running), the dependency is not stated directly on the init.d file installed in the user's system, instead the dependency is commented prefixed with #USEHOWL string. When compiling the software, the init file present on ${FILESDIR} is then edited with sed to remove the line if howl is not requested, to uncomment it when howl is requested, and to change the service name from mDNSResponder to avahi-daemon if avahi is used.