Down with forked-daad, up with mt-daapd

I have a page that is a popular destination for music lovers out there.  It's my post on running forked-daapd on CentOS.  It was a great little post at the time, and was needed.  It was the daapd server at the time that had the most recent activity in development, so it was the one I opted to use.

It was rather ugly to get installed, frankly.  It had so many dependencies to other libraries, all in an attempt to make it "easier to code".  But it definitely helped me realize something : all of you open-source wookies out there seem to think, "hey, a  new library!  I should get in front of this bleeding edge so that all of my L337 friends think I'm the bomb!"

Frankly, I hate you punks.

Why the hell should I have to install 5 different libraries for each package only to have those libraries used ONLY by that package?  That's ridiculous, and frankly, I'm not gonna put up with that crap any more.

No more packages that require any more than one  obscure library, or it's on my hitlist.  Perhaps you will understand if I explain this with the forked-daapd server setup.  It required a recompile of sqlite3, antlr3, and a number of other packages that only forked-daapd needed.  I went through the hoops once.  BUT, every time I updated the system and the sqlite package was updated, or some other dependency was updated, I had to recompile every damn piece of the puzzle, and sometimes they wouldn't even compile any longer!  I am NOT going to release packages for something old, and something that was causing a pain for me.

So, I went back to the older mt-daapd service.  Wary of what I might have to install, I threw the source down and fired off the compiler.  It needed a few things.... but they were all provided by the distribution!  After not having my wife iTunes be able to play the networked data, I had it up and running fairly quickly!

For all of those who are trying to use forked-daapd..... just give up and go with mt-daapd .  It works just as well!

Finally, the How-To for forked-daapd on CentOS 6.2 64 Bit

FYI, I have superseded this post - I got very frustrated with recompiling the whole kit and caboodle every time I did an update just to have this running.  So, I opted for the mt-daapd server, and it was easier to install, less external dependencies, and still did everything I needed it to.  Try this post before continuing on!

Okay, I'm finally getting to the point of writing up how I finally got forked-daapd installed on my CentOS 6.2 64 Bit media server. It was a pain, but it works.

My process was : try to configure, compile, and install. If it failed, deal with the problem and repeat.

Simple process, but there was a LOT that was problematic.

First, the dependencies (you will need the rpmfusion repository configured) :

yum install gcc glibc-devel avahi-devel ffmpeg-devel libplist-devel taglib-devel flac-devel libunistring-devel java libgcrypt-devel mxml-devel libevent-devel alsa-lib-devel gettext-devel libconfuse-devel gperf zlib-devel ant ant-antlr ant-apache-bcel ant-junit ant-trax antlr tcl-devel git

You will note that we need a stringtemplate RPM as well (hard to find, so I slapped a copy at http://svn.silverhawk.net/files/stringtemplate-3.2.1-3.jpp6.noarch.rpm). I needed to search a bit for one, as it's not in the regular distro, but grab that one.

This should get ALMOST everything. Note that sqlite has to be recompiled. In order to satisfy dependencies, I rebuilt that into an RPM to replace what was there (this one has the option required for forked-daapd). A few others were not found, so I slapped them together, building a number of these RPM's. Currently, the source RPM's are available here :

http://svn.silverhawk.net/files/antlr3-3.1.1-10.el6.src.rpm
http://svn.silverhawk.net/files/libantlr3c-3.1.3-0.2.src.rpm
http://svn.silverhawk.net/files/sqlite-3.6.20-2.el6.src.rpm

You will also want to install the -devel packages for each one once you've built good system packages. You can seamlessly replace any sqlite packages. Note that upgrades might not work with the custom sqlite, but it's easy to grab the source RPM for the upgraded sqlite, add the param, and then upgrade it manually, then the system should update again.

Once those dependencies are installed, you must toss in mxml (available from http://svn.silverhawk.net/files/mxml-2.7.tar (after compiling and installing, copy the mxml.pc file into the appropriate location, mine was /usr/share/pkgconfig/), and then libavl (available from http://alioth.debian.org/~jblache/forked-daapd/libavl_0.3.5.tar.gz) :

1. Edit the make file, and Comment out "CFLAGS ?= -O2 -fomit-frame-pointer -pipe -mcpu=i686 -w"
2. Add a new CFLAGS Line :

   CFLAGS = -fPIC -O2 -fomit-frame-pointer -pipe -Wall -g

3. Replace all "$(LIBRARIES)" variables with "$(LIBRARY)" due to a bug.
4. Save and Close
5. Build and install :

   gmake -f GNUmakefile ; gmake -f GNUmakefile install

Now, open the forked-daapd source code, but grab a specific version (you might need to install git if you didn't get it installed earlier) specific for the iTunes 10.5.x functionality (otherwise it will time out) :

1. mkdir tmp
2. cd tmp/
3. git clone https://github.com/CBGoodBuddy/forked-daapd.git
4. cd forked-daapd
5. git checkout itunes_v10_5
6. autoreconf -i
7. ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-flac --enable-musepack --enable-itunes
8. make
9. make install

To run the app, first modify your configuration (/etc/forked-daapd.conf), and then add a user :

useradd -s /sbin/nologin -M -r -d /var/cache/forked-daapd -c "iTunes service account" daapd

forked-daapd in CentOS 6.2 64 Bit

Hey, folks; I was setting up forked-daapd in CentOS 6.2 (64 Bit), and ran into a few problems. One of the most recent was that the libantlr3c was not being used (headers were found). I found that if I add a --enable-64bit to the configure line (I used an RPM spec file), it will create it for 64 bit, which is really what I needed. I realized this when it kept failing to configure the forked-daapd with an error about libantlr3 and a missing function, and when I looked in the config.log for the error, the linker was ignoring the 32 bit libraries. (If you haven't enabled 64 bit, it is 32 by default, and you would have to use a 32 bit compiler by default if you wanted to). So, there is another quick hack.