Herman I. May

Herman I. May

The May Family


Building a better jukeBox

Apple's iTunes application — and integral and groundbreaking component of the iLife suite — was a hit from its original release. Based upon the SoundJam MP codebase, iTunes evolved quite quickly from its original release in the spring of 2001. However, one of the major complaints of the original iTunes was the fact that it lacked the broadcast capabilities of its predecessor.

This changed on 28 April 2003 when, in conjunction with the debut of the iTunes Music Store (ITMS), Apple released iTunes version 4.0. In addition to the ability to purchase and download music from the ITMS, this new version represented the return of an ability to broadcast the contents of one's iTunes library and allow for third party streaming of the music files.

Much lauded and anticipated, this feature provided the option of creating and maintaining a central repository of music files that could be shared with any other iTunes user. This functionality originally extended beyond the local subnet and allowed for streaming access from anywhere on the 'Net.

Alas, the robust nature of the return of this feature did not last for long. Twenty-nine days following the initial release of iTunes 4.0, Apple released an "update". The decimal revision (4.0.1) restricted streaming to the local subnet. Media reports quoted Apple as attributing this restriction to proactively addressing the potential for music piracy. Some saw this, instead, as surrendering to the demands of the RIAA. Nevertheless, it was a lamentable day.

It was during that thirty day period that I commenced the process of consolidating all existing music files on the various machines around the household onto a centralized server — Scheherazade. This project freed many scores of megabytes of disk space from Icarus, Ariel, and Brunhilde. Being a server, Scheherazade had room to spare and it was no problem whatsoever to accommodate the several gigabytes of data represented by these files.

Having the ability to launch iTunes, select the iTunes share, and listen to music on demand — whether at home, work ... wherever — was a great capability, while it lasted. In fact, it was at work that I made the best use of this capability. Rather than take a handful of CDs to work everyday, it was great to simply tune-in to the catalog at home.

The restriction of capability manifest by the release of 4.0.1 was a great disappointment. I immediately began to search for an alternate means of accomplishing the functionality of the original feature.

Finding a viable alternative did not take long. For over six months, I made use of the tunneling tricks offered in two MacOS X Hints postings (one, two). This procedure was quite functional and served as an adequate replacement ... for a while.

Most of the next six months was spent ripping and storing the balance of our music collection. At the onset of the project, there were around 400 tracks available for listening. In fact, quite a bit of the remaining work was completed during the 2003 Christmas holiday. The dawn of 2004 marked the conclusion of the project; the total track count was just over 5000 using approximately 22Gb of disk space.

I was not fully content with the result, however. It is all well and good to have such an easy means of hosting the music catalog from the server. However, in order to make use of iTunes to facilitate the broadcast, the user under whose account the library has been constructed and stored must be logged-in to the GUI. This is an unnecessary consumption of resources (RAM, processor cycles, etc.) and I was intent on finding an alternative.

Recalling the second of the two MacOS X Hints articles mentioned above, I paid a visit to the project home for daapd.

Despite the rather lengthy list of dependancies, it was no problem to build, install and run. The daemon supports the use of a cache file; so, once the first rather lengthy scan of the library hierarchy is complete, a restart is a breeze. There are, however, several drawbacks to the use of daapd.

The developers of daapd do not seem to have the means at their disposal to make use of the built-in ZeroConf broadcaster available on MacOS 10.2 and later — mDNSResponder. One seems to be required to install the POSIX version, mDNSProxyResponderPosix. This functions, but it requires yet another daemon to support the bradcast service. In addition to the latter, daapd is not multi-threaded; nor does it support playlists. For a relatively modest music database, this is probably acceptable. However, when dealing with several thousand tracks, it can become tedious to scroll through the entire list in search of the desired tunes. So, it was back to the search.

An alternative DAAP daemon was quickly located. I had seen references to mt-daapd (multi-threaded daapd) on several forums with reference to the creation of a DAAP server for Linux. I visited the project page and downloaded the source. Things did not go well.

Though there is only one dependancy, libid3tag, my attempts to compile kept hitting one wall after another. Since libid3tag was also a dependancy for daapd, it was already in place. Nevertheless, the builds kept failing. Test builds on a MacOS X 10.3.x machine were just about flawless. The only error being a notation during the configure run that suggested that termio.h support was lacking (more on that in a moment). Otherwise, make progressed to completion.

As time permitted, I began to compare the differences between 10.2.x and 10.3.x. The most prominent difference is the the vintage of the header files installed with the respective "Developer Tools". There have been no tool revisions for 10.2.x since the December 2002 update. Thus all of the header files date from November 2002, while those on 10.3 date from September 2003.

Correction of the first terminal build error required that I copy one of the header files from a 10.3.x box to Scheherazade. Unfortunately, while that cured the first issue, it revealed another. The build process progressed almost to completion, but failed during the final linking.

Much analysis of the configuration and Makefile(s) ensued over the next couple of weeks. I found the approximate point at which the build was failing, but I was not savvy enough with deciphering the command structure to allow for a fix.

It was at this point that I contacted the project admin. He was very helpful and, based on the portion of the compile transcript supplied, was able to enlighten me with respect to a solution. I am now up and running with mt-daapd on Scheherazade (MacOS X 10.2.8) and using fewer server resources as a result.

The following is what it took to successfully build mt-daapd on 10.2.8:

Create a link to point configure toward termio.h
(Apple has replaced the termio herader file with termios. I simply created a symbolic link in /usr/include that directed a search for termio.h to termios.h)
ln -s termios.h termio.h
Replace the 10.2.x version of dirent.h with a version from the XCode.
(Running diff on a copy of dirent.h from both installations revealed several differences. Rather than try to customize the file until it worked, I simply replaced it. A comment from the mt-daapd developer summed it up best: "So much for POSIX, I guess.")
Uncomment the line excluding the function "strcasestr" in src/Makefile.
(The developer expressed puzzlement as to why this function is not supported in 10.2.x. However, in following his advice the build progressed to completion and has been running with seemingly no side effects.)
change: #am__objects_3 = strcasestr.$(OBJEXT)
       to:   am__objects_3 = strcasestr.$(OBJEXT)

In the end, I succeeded in my task of creating a DAAP broadcast server that was neither a) limited to the local subnet nor b) required a logged-in GUI user. I also discovered that all DAAP daemons are not created equally and that persistence and contact with the developer can pay off in big ways.

Advantages of mt-daapd over daapd:

fewer dependancies
support for static and dynamic playlists
web-based administration
originally published: 07 March 2004


HIM envelope
last BBEdited: 2004.04.29