Project:Sound/Mt-daapd maintainers guide
mt-daapd
Introduction
media-sound/mt-daapd 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 rhythmbox, too.
This package also replaces the old media-sound/daapd 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 mt-daapd respect to daapd 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, mt-daapd 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 mt-daapd in Portage are able to run multiple instances of the daemon itself.
Setting up a new mt-daapd instance is simple, and it's like the way multiple network interfaces are configured: just symlink /etc/init.d/mt-daapd to /etc/init.d/mt-daapd.identifier. Once that is done, the new mt-daapd.identifier service will look for the configuration file in /etc/mt-daapd.d/identifier.conf.
When using the simple
mt-daapd service, instead, the configuration remains in /etc/mt-daapd.conf, so there's no problem in leaving the old-style configuration in place when adding a new instance.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 mt-daapd sources (already accepted upstream).
Multiple instances does not currently work when using howl/avahi mode (see later on), so
mt-daapd should be built with -howl to use them.Interaction with mdns responders
mt-daapd 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 howl.
The internal version does not conflict with the external responders and it's usually the more tested one. It's also currently the only safe way to get more than one
mt-daapd session running on the same box.Support for avahi responder should be currently worked on by upstream; in the mean time for people wanting to use that instead of howl, the ebuild make use of avahi's compatibility layer with howl. The howl useflag has a conditioned avahi useflag, when that is enabled, it does depend on avahi instead of howl, 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.