eean

As Seb points out, it is necessary to point out how awesome native last.fm support is. It is.

One (as-yet unintegrated feature, it will probably be put in shortly after the string freeze ends) great feature of Last.fm is the custom radio station. Just enter some of your favorite artists and it puts together a stream of those artists and their related artists. Feel free to try a couple of mine, though of course its better if you pick your own artists.

Leo Franchi added a .protocol file to be installed with Amarok to support the lastfm:// protocol for Konqueror, like the links in the previous paragraph. Though Makefile.am isn't ever fun, it was a straightforward task: an app installing support for new protocols is obviously an issue that KDE decided to provide a solution for.

I immediately got to thinking it would be cool to add such protocol support to Firefox as well. In Windows a registry edit is all that is required. After some help from irc.mozilla.org and Google, it appears to be completely impossible for a application to install a protocol into vanilla Linux Firefox. The user has to go in and add an entry to about:config manually. One suggestion I got was to write an extension, I asked if an extension could be installed from outside Firefox - no. Obviously not useful (though perhaps something last.fm should look into).

If you have a Firefox built with Gnome support (eg, not a Firefox binary downloaded from mozilla.org), you can use gconftool-2 to add the necessary settings. Gconftool-2 is hardly ideal for what should probably be an install-time operation, it doesn't appear to do settings for all users (though I could be wrong).

Our part-time Codeine hacker part-time radio personality Max Howell has a new name for his show: "Max'd Out". The website even has a new look. Be sure to ask him about it.

To do a simple SVK commit of just a couple files changed (and not merge everything, as SVK seems designed to do) I have to run the following command:

svk merge --change 5324 //amarok/ian //amarok/trunk

Which of course assumes that the files you want to commit only changed in one or sequential commits. I kind of feel like SVK is two steps forward (a local revision system), two steps backward (a real pain to actually commit anything remotely). I really want a revision control system for developing the DAAP library and media device plugin, so I'll probably just deal with it. If all else, I can always just copy the files into a normal SVN checkout and commit there.

I've taken something of a break from DAAP work, though not really. For the past couple of days I've been working on finishing the last.fm support that Seb started, which was mostly a backport of Qt4 code from Muesli's official Last.fm Player. With a few fixes of the existing code, I was able to get it to login and retrieve the URL of the stream. It was in-fact almost in beta1, until Mark noted that I had used a synchronous get function introduced in KDE 3.4. I really needed a synchronous function since without refactoring a lot of code it was necessary to turn the "fake" lastfm:// URLs into the real http:// MP3 stream URL within the EngineController::load function. KDE 3.3 lacks a synchronous function that doesn't put up a bunch of annoying popups.

The solution was to create a proxy server: this way the proxy server URL could be returned immediately. And a proxy server would have to be created anyways since the Last.FM stream includes "SYNC" commands that let the client know to fetch new metadata. This is actually why I was working on Last.FM support: thanks to Apple's quasi-DRM, DAAP requires special headers be sent with the HTTP requests so I knew I would eventually have to create a proxy server anyways.

So I created a really basic proxy server using QSocket and QServerSocket. It worked with the Helix Engine, but with the Xine Engine it would just hang all of Amarok (Alexandre looked at the Xine code, it actually has an infinite loop in it). So Mark made the server threaded. He says that this still did not work, which doesn't make sense to me (he never committed this code). Currently Mark is working making the proxy server be a separate process, as just a ruby script (less overhead then starting a QApplication).

And oh yea... go Japan! On that note, this morning I was turned into a USA fan into a Ghanaian fan. sigh It would've been fun to see the USA get into the quarter finals again, but we just didn't play that well this year. So too bad USA, hooray Ghana!

SimpleDaapClient is a Ruby script that connects to a non-Apple DAAP server (though old iTunes probably works), gets a listing and produces an XSPF playlist of the hosts entire database. The XSPF file contains much of the metadata so that Amarok can display it all. It turned out that Amarok didn't support XSPF files that specified their location. The alternative - to look up the song based on album and artist - was the only thing supported. So I had some fun debugging both the Ruby script that made the XSPF file and the decoder in Amarok at the same time.

I just put what I think are probably the finishing touches to SimpleDaapClient. Yesterday, Mark pointed out that if the recursive solution was too big for the stack, why not just make the stack bigger. Which I did, so I haven't made an iterative solution like I said I would last time. It is just a prototype after all. Though... I probably should find an iterative solution for Amarok itself.

There's something satisfying about writing a Ruby script that uses 3x the memory of kdevelop.

To use SimpleDaapClient.rb, first download it, make it executable, and find & replace "localhost" with the DAAP server of your choice.
Then bump your stack size and run:
ian@wasabi ~/soc/DAAP/trunk $ su
wasabi trunk # ulimit -s 65536
wasabi trunk # su ian
ian@wasabi ~/soc/DAAP/trunk $ ./SimpleDaapClient.rb

This will create a /tmp/daap.xspf. So, just do something like `amarok /tmp/daap.xspf`. You need Amarok from revision 551863 (the newest at the time of this blog).

And now... back to coding in C++ full time probably. I'll miss you Ruby!

Now that I'm settled back in beautiful Kirksville, I've started working full steam on my Google Summer of Code project, which is to add iTunes music sharing to Amarok (also known as "DAAP support"). Currently the only maintained DAAP library is part of the Banshee project, so its in C#. Libopendaap and kio_daap (which has a fork/branch of libopendaap) hasn't been touched in a year and doesn't work for me, I think due to 64-bit issues (which I tried to diagnose, but it was entirely mysterious to me). Rhythmbox has its own implementation of DAAP, written as a SOC project last year and uses glib, so it quickly scared me a way.

So at the risk of being accused of "not written here", I've decided to write my own DAAP implementation, at least for the client-side (I'm still holding out hope for mt-daapd integration). I could make it a separate library for use by other KDE applications (Juk?); I will at least not couple it with Amarok to leave that option open (though I might go ahead and use metabundle...).
To become familiar with the protocol, I've written a Ruby script (it doesn't do anything yet, but its on SVN). I think it will be possible to actually turn it into an Amarok script to provide bare-bones basic DAAP client support - basically the user would type in the IP address and all the tracks would be loaded into the playlist.

Currently it gets a 'stack level too deep' error when trying to get a database listing, which I blame on learning LISP last semester. It uses the same sort of recursive algorithm we used in class all the time. It shouldn't be too difficult to rewrite it iteratively.

One "interesting" feature of the iTunes implementation of DAAP is that it requires an almost DRM-like messed up MD5 hash, meant to reduce interoperability of iTunes with others. Luckily David Hammerton of libopendaap has already figured it out. If you have a spare minute you might check out that code, its pretty hilarious. I've never liked Apple, now I have a reason not to. (This means my Ruby prototype won't ever work with iTunes).

A thanks also goes to James Willcox (snorp) of the Banshee project for pointing this out and providing other useful pointers. I consider Banshee to be Amarok's most significant competitor in the open source world, but I think we all recognize that our real competition isn't open source.

On a similar note, I contacted Cole, a fellow SOCer who is implementing DAAP for XMMS2. He also determined that none of the current DAAP implementations are satisfactory and is implementing his own library as well. Though our conflicting library requirements mean we can't directly colloborate, I think we will be comparing notes as the summer continues.