mt-daapd maintainer's guidemedia-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's also more performant and 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 alike 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.
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).
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.
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. The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-2.5 license. The Gentoo Name and Logo Usage Guidelines apply. |
|