Linux/FreeBSD DAAP (iTunes) and MPD media server with support for AirPlay 1 and 2 speakers (multiroom), Apple Remote (and compatibles), Chromecast, Spotify and internet radio.
Go to file
Julien BLACHE 2cb67743fc Add service type to the "ALL FOR NOW" message 2010-01-20 18:17:04 +01:00
src Add service type to the "ALL FOR NOW" message 2010-01-20 18:17:04 +01:00
.gitignore Add documentation 2009-06-12 13:02:39 +02:00
AUTHORS Update AUTHORS 2009-06-12 13:00:40 +02:00
COPYING Add GPLv2 license text 2009-06-12 13:00:40 +02:00
ChangeLog Add documentation 2009-06-12 13:02:39 +02:00
INSTALL Documentation update 2010-01-10 11:27:19 +01:00
Makefile.am Add a manpage for forked-daapd 2009-09-21 21:26:21 +02:00
NEWS Add documentation 2009-06-12 13:02:39 +02:00
README Document the Remote pairing process 2010-01-17 11:16:17 +01:00
config.rpath Add mandatory automake files 2009-04-01 19:27:03 +02:00
configure.in Limit signalfd.h header check to linux platforms 2010-01-09 13:40:28 +01:00
forked-daapd.8 Remove -y option, as it doesn't actually exist 2010-01-05 18:32:00 +01:00
forked-daapd.conf Add itunes_overrides parameter 2009-11-28 10:55:43 +01:00

README

forked-daapd
------------

forked-daapd is a DAAP and RSP media server, with support for Linux and
FreeBSD. It is a complete rewrite of mt-daapd (Firefly Media Server).

DAAP stands for Digital Audio Access Protocol, and is the protocol used
by iTunes and friends to share/stream media libraries over the network.

RSP is Roku's own media sharing protocol. Roku are the makers of the
SoundBridge devices. See <http://www.roku.com>.

forked-daapd is a temporary name that should change to something else if
someone can come up with a good name for it.


Supported clients
-----------------

forked-daapd supports iTunes clients as well as a number of devices similar
to the SoundBridge.

It should be able to serve your media library to any client supporting DAAP
or RSP.

A single forked-daapd instance can handle several clients concurrently,
regardless of the protocol.


Pairing with Remote on iPod/iPhone
----------------------------------

forked-daapd can be paired with Apple's Remote application for iPod/iPhone;
this is how the pairing process works:
 - start forked-daapd
 - start Remote, go to Choose Library, Add Library
 - prepare a text file with a filename ending with .remote; the filename
   doesn't matter, only the .remote ending does. This file must contain
   two lines: the first line is the name of your iPod/iPhone, the second
   is the 4-digit pairing code displayed by Remote.

   If your iPod/iPhone is named "Foobar" and Remote gives you the pairing
   code 5387, the file content will be:

      Foobar
      5387 

 - move this file somewhere in your library

At this point, you should be done with the pairing process and Remote should
display the name of your forked-daapd library. You can delete the .remote file
once the pairing process is done.

If Remote doesn't display the name of your forked-daapd library at this point,
the pairing process failed.

This will usually be because the .remote file did not contain the correct name
or pairing code. Start over the pairing process and try again.

If in doubt, enable a more verbose level of logging and check that forked-daapd
receives the mDNS announcement from your iPod/iPhone when the pairing code is
displayed by Remote (you can also use avahi-browse for this purpose, see below).
If not, you have a network issue and mDNS doesn't work properly on your network.

If you are unsure about your iPod/iPhone's name, here's how you can check for
the correct value:
 - in a terminal, run avahi-browse -r -k _touch-remote._tcp
 - start Remote, goto Choose Library, Add Library
 - after a couple seconds at most, you should get something similar to this:

+ ath0 IPv4 59eff13ea2f98dbbef6c162f9df71b784a3ef9a3      _touch-remote._tcp   local
= ath0 IPv4 59eff13ea2f98dbbef6c162f9df71b784a3ef9a3      _touch-remote._tcp   local
   hostname = [Foobar.local]
   address = [192.168.1.1]
   port = [49160]
   txt = ["DvTy=iPod touch" "RemN=Remote" "txtvers=1" "RemV=10000" "Pair=FAEA410630AEC05E" "DvNm=Foobar"]

The name of your iPod/iPhone is the value of the DvNm field above. In this
example, the correct value is Foobar.

Hit Ctrl-C to terminate avahi-browse.


Supported formats
-----------------

forked-daapd should support pretty much all media formats. It uses ffmpeg to
extract metadata and decode the files on the fly when the client doesn't
support the format.

However, ffmpeg is not necessarily very good at extracting metadata, so some
formats may cause problems. FLAC, Musepack and WMA use custom metadata
extractors to work around that.

Formats are attributed a code, so any new format will need to be explicitely
added. Currently supported:
 - MPEG4: mp4a, mp4v
 - AAC: alac
 - MP3 (and friends): mpeg
 - FLAC: flac
 - OGG VORBIS: ogg
 - Musepack: mpc
 - WMA: wma (WMA Pro), wmal (WMA Lossless), wmav (WMA video)
 - AIFF: aif
 - WAV: wav


Playlists
---------

forked-daapd supports M3U playlists. Just drop your playlist somewhere in
your library with an .m3u extension and it will pick it up.

Support for iTunes Music Library XML format is available as a compile-time
option. By default, metadata from our parsers is preferred over what's in
the iTunes DB; use itunes_overrides = true if you prefer iTunes' metadata.

Smart playlists are not supported at the moment.


Library
-------

The library is scanned in bulk mode at startup, but the server will be
available even while this scan is in progress. Of course, if files have gone
missing while the server was not running a request for these files will
produce an error until the scan has completed and the file is no longer
offered. Similarly, new files added while the server was not running won't
be offered until they've been scanned.

Changes to the library are reflected in real time after the initial scan. The
directories are monitored for changes and rescanned on the fly.

Symlinks are supported and dereferenced. This does interact in tricky ways
with the above monitoring and rescanning, so you've been warned. Changes to
symlinks themselves won't be taken into account, or not the way you'd expect.

If you use symlinks, do not move around the target of the symlink. Avoid
linking files, as files themselves aren't monitored for changes individually,
so changes won't be noticed unless the file happens to be in a directory that
is monitored.

Bottom line: symlinks are for directories only.