My beagleboard-xM wifi router is almost a year old; old enough to take on more responsibilities. Most recently it became the new home for my installation of tracker, which I migrated from a publicly accessible linode server. Soon I’ll be giving it the task of acting as an iTunes server.

After using tracker in it’s new home for a few months, I realized that disk operations on the beagleboard were quite a bottleneck. After shopping around, I migrated the Arch Linux installation from an Amazon Basics 16GB MicroSD card to this super-fast Samsung card. There’s a night-and-day difference between the two cards. With the Amazon card, saving an item in tracker to an sqlite3 database would take 4 seconds, but with the new card it’s immediate.

Back to the iTunes server project. When I first got the idea for the project I did a quick search on Github and found some prior art written in node.js, which is the language I wanted to use. The node-daapd project seemed the most promising foundation to build upon, so I clicked the Fork button. The latest commit was from 2013, so it wasn’t a surprise that the server didn’t work with the latest version of iTunes. Over a period of two days I figured out why and eventually got it to work with iTunes 12. Using forked-mtdaapd as a guide, I added a txtRecord segment to the mDNS response. iTunes now saw the music source, but it still didn’t quite work. I then checked out the session-related code and thought it weird to hand out a session id of 0, so I changed it to start at 1. Once I did, communications with iTunes progressed a bit further. There was a similar scenario with revision ids, specifically that iTunes would request id 1 at first connection and as long as I told iTunes that I was returning a revision greater than 1 it was happy. The last major thing I changed was to logic related to update polling. It’s still not finished, so I’ll spare you those details.

One of the larger TODO items on my list is to store the song library in an sqlite3 database. This should make startup times more tolerable, and future-proof the service to handle more MP3s. Eventually I’d like to provide support for album art, but I have a feeling that will require me to capture communication with a real iTunes share/server. It looks like forked-mtdaapd supports album art, but I haven’t spent much time trying to decipher that code yet.

If you want to follow my progress, check my node-daapd repo.