Introducing PodSleuth

PodSleuth is a new project I started last May that aims to probe, identify, and expose properties and metadata bound to iPods. It obsoletes libipoddevice, which had the same goals, but due to many reasons ended up being a mess of spaghetti code and hacks due to effectively being obsoleted overnight about a year ago when Apple made a particular firmware release.

PodSleuth takes the many lessons learned from libipoddevice and evolutions of the iPod itself and implements hardware support in a more future proof, yet backwards compatible and easy to maintain way.

The Technical

The core of its design is platform independent, although PodSleuth in its current and complete form is most usable in the context of HAL. A HAL layer is provided that is used now in Banshee, and we would like to see other certain iPod libraries at least optionally support PodSleuth. This layer is implemented as a HAL callout. Because the callout runs as the same user as the HAL daemon (typically root), it is allowed to cleanly perform operations that were implemented as hacks in libipoddevice (like reading from SCSI code pages).

The metadata that PodSleuth collects is then merged into the HAL device as properties. Once the PodSleuth callout ends, HAL finishes probing the device and exposes the iPod on the Global Device List (GDL) where the mount daemon (i.e. gnome-volume-manager) will then mount the iPod in a manner accessible to the user session. The key here is that by the time the iPod is exposed on the GDL, all PodSleuth properties will have been merged into the device. This makes application and user session library support for PodSleuth properties very easy and straight forward. One need only check for org.podsleuth.version on the device to check if PodSleuth ran against the device. If that property exists, other properties will be available that expose iPod metadata.

if (device.PropertyExists ("org.podsleuth.version")) {
    // We have a PodSleuthed iPod, it's ok to expect 
    // at least the minimum set of properties

    Console.WriteLine (String.Join (", ", device.GetPropertyStringList 

One of the most important changes that affects the end user directly is that the iPod will always be supported based on metadata extracted from the plist file located in the SCSI code pages. This means that even if the iPod is not found in the model table, no functional limitations will be imposed. That is, the model table is now only purely cosmetic (for presenting things like shell color and the right icon). This is in contrast to earlier versions of libipoddevice.

Additionally, PodSleuth sets the info.icon property in HAL which means that once we get new icons for the new iPods and update the existing ones to follow the new required naming specification, the proper iPod icon will finally show up in Nautilus and elsewhere (provided you are running a recent enough GNOME). A cute thing indeed.

The Files

PodSleuth will see its first official release within the next week, alongside a new ipod-sharp release, and Banshee 0.13.2. All of these releases spell out support for new iPods (Classics and Nanos), so stay tuned. PodSleuth is developed in GNOME subversion under the podsleuth module.

The Unfortunately Political

The fun part is that PodSleuth is written in C# of course, a detail that I like to think doesn’t matter, but it certainly and most unfortunately offends many for various reasons. There are two lovely facts that I like to point out when opposition to my language of choice for this project arises:

  • Because PodSleuth is not used as a library, any application written in any language with HAL support can benefit from PodSleuth. I could have written PodSleuth in shell, and it would not affect applications wishing to support it.

    Furthermore, PodSleuth requires only the ECMA approved portions of Mono (which is a 100% open source project and has a strict policy to keep patented code out) and Mono.Posix (which is an open source library wrapping POSIX system calls). Therefore there are no patent concerns (although I know the facts don’t matter to the noisy zealots).

    What matters on the technical side of this point is that most modern distributions ship at least this core subset of Mono these days, so I feel the dependency argument falls apart here as well.

  • My favorite argument against PodSleuth because it is Mono-based comes from the crowd that hates Mono for unfounded political reasons, yet require free software support for their iPod.

    Let’s see, the iPod is closed hardware, proprietary software, contains DRM, supports proprietary formats (doesn’t even have any open format support), and just recently added a hashing mechanism against the primary track database to lock out third party clients. I’m not sure if I’ve ever come across a more proprietary device, yet this zealot crowd has the nerve to scream about Mono!

    This theme is unfortunately all too common in our community (“Oh, it’s OK to run a Mac! Just don’t use Windows! The Mac is shiny too!”).

    In response to this very argument a few days ago in the #banshee IRC channel and mocking what could be seen as a double standard, Jorge Castro quipped,

    “I value freedom so I refuse to use Mono, oh look, a new iPod!”

    So true, so sad. On a somewhat related topic, I recently looked at the APSL next to the Ms-PL. Now that’s funny.

The Bottom Line

There is no reason an application or library focused around iPods shouldn’t support PodSleuth. Regardless of political alignment, PodSleuth is designed in such a way to make it very easy to optionally support. Supporting it technically places zero dependencies on a library or application. If a distribution happens to provide PodSleuth, then why not take advantage of the properties that would be readily available to you? They’re just strings in HAL! If the properties exist, use them. If not, fall back to what you’re doing today.

Think of your users! There’s a very small majority of users out there who will actually care about what a PodSleuth is, let alone what it’s written in. They just want their iPod to work, and PodSleuth provides a very solid hardware metadata layer in a clean language and platform agnostic way. Of course, these users should already be using or are already using Banshee, which has provided this experience from the get-go.

People who care about the political issue and oppose the platform shouldn’t be using iPods anyway, lest they be hypocrites.

22 Replies to “Introducing PodSleuth”

  1. I for once welcome my Podsleuth overlords, I’m already using it to great success – and since #486996 went away I can only be pleased to see the cuteness of a proper white iPod icon in my Banshee. Great work Aaron

  2. I agree completely with your arguments here. Too many refuse to see things for what they are…

  3. Hi Aaron, great work as ever.
    What is the best way to submit extra data for the ipod-model-table? For example, my orange iPod shuffle (2nd gen) has a serial number ends “XR3”, a model number of “A1204”, and an EMC number of “2125”. If that makes any sense.

  4. It’s sad you have to defend your choice of language. Every free software hacker should use the language they feel most comfortable with.

    I haven’t used PodSleuth yet, but it looks very promising. Ipod support is a very important feature to have on the Linux desktop and I don’t care about the technical details of the implementation, as long as it can be used by programs written in another language and is free software. Your software seem to meet those requirements :)

    So you have my vote. Keep up the good work!

    If people dislike mono, either they should rewrite PodSleuth in their language of choice or shut up. Don’t listen to the vocal minority of zealots who say they care about freedom more than features. I’m sure even those people use proprietary video drivers (nvidia), codecs (ffmpeg) or plugins (flash) :)

  5. Some quick saturday morning pedantry: mp3 and AAC are _open_ formats (unlike, say, windows media formats), they’re just patent-encumbered (allegedly at least, I wouldn’t really know) and require a license for various things in various places of the world. Your argument is still spot-on of course.

  6. I can see why you want to use mono, and I don’t have problems with that perse – but I do have problems with having to install mono only because I want to install a music player which depends on it. It’s rather large for just a small library. This kind of lowlevel stuff should be C or C++, and DE agnostic, to not force heavy deps on ppl. Why would I want to have mono installed? I wouldn’t otherwise need it…

  7. jospoortvliet: Mono /is/ DE-agnostic. Also, Mono itself isn’t really all that large (I have all of the mono packages installed including winforms, Olive, Data, Monodoc, the -doc and the -devel packages – total used space is under 150 MB – and that’s for both the 1.1 and 2.0 runtimes) and as time goes on, more and more apps will use it anyway, so the “cost” of having it gets smaller and smaller over time.

  8. I think you (and many others) are missing one of the main mono problems. From the outside it looks a lot like Novell is pushing mono much harder then is healthy. Mono gets used in places where its the wrong _technical_ choice. Beagle is probably the prime example here. It has with any doubt been a great application to develop from a debugging-mono kind of view, but its memory issues is still caussing people problems. All because somebody made the wrong decision with choice of language.

    My point is simply that Novell is pushing mono so hard that it is being used in applications where it not the best choice. Combine this with the political issues around using MS technology, and its not hard to understand why some people get upset when useful stuff is written with mono.

    Anyway, it looks like you’re doing good stuff… Keep it up…

  9. A small install of Mono is barely larger than standard system libraries, you can get it down to 8 megs on disk.


  10. 150MB to support a single library isn’t exactly small. In fact, I’d say it’s absolutely huge and perverse.

  11. Very cool. Does this mean we’re getting close to podcast and playlist syncing in Banshee?

  12. Jonas: clearly you didn’t read what I said… 150MB with EVERYTHING installed, which is FAR MORE than is required for this. If you remove the -devel, -doc, and -debuginfo packages and all of the locale po files, that likely drops to under 50MB. Then subtract the winforms, olive, moonlight and all the database stuff, and you likely find it down to under 25MB.

  13. Anonymous and Jonas, you guys did not read what I said, a small installation takes about 8 megs.

    In fact, I just found a blog post where I summarized the debian package for Mono for the requirements from PodSleuth, it is 7.5 megs:

    That is the on-disk usage, the download is 2.5 megs or so.


  14. @Miguel: 8meg is rather doable, yes. I would not hate it if that would be needed for a mono application. But it’s way too much for a small library needed by Amarok… Most of these libs don’t need any other crap besides the standard C libs. Sometimes glibc, that’s doable. But I’m already annoyed by the Ubuntu version of libgpod, which depends on GTK2+ – pretty silly, it’s the only reason I have it installed on my laptop. I don’t care about gtk nor mono libs on my main system, dualcore + 3gb ram – it can handle some redundant libraries. But my 6 year old laptop can’t, and I try to get rid of everything I don’t really need. So I would vote against using this library because it needs mono, simple as that.

  15. Sounds very positive. Is it easy to implement things like those on Mono? Did you even have to touch native code to talk to HAL?

  16. WRT disk space: It might be possible to package mono in such a small package, but is it possible to get it that way in the popular distros?

    Disk space is not the main concern, the RAM is, it won’t be 8MB in ram, more likely 10x that.

    This thing runs as root, so you’d have mono running as root. Not a great idea.

    wc -l `find src -name \*.cs` says 2790 lines. Having the mono overhead for that much code does not seem so good.

  17. Banshee is an awesome program and frankly I don’t care which language its written in because its so good. Are we going to see iPhone support? What ever happened to the list view changes?

  18. anon: try turning that question around: if you are writing an program that will run as root, why _wouldn’t_ you choose a language with automatic memory management and array bounds checking?

    Also note the nature of this program: when an iPod is plugged in, the program gets run by HAL. It inspects the device, annotates the device info in HAL and exits. There is no long-running daemon process sitting round eating your memory.

    Assuming you have the resources available to run such a transient program, and it completes its job in a reasonable amount of time, the language choice does not seem to be that big a deal.

  19. Pingback: joe shaw /
  20. Hurrah for ipod support!

    I converted a blista user to linux becuase their ipod shuffle was mounting and unmounting in quick succession and therefore they could not transfer songs to it. I put in a live linux cd andshowed them that their shuffle would stay mounted. They decided that they preferred an OS that supported their shuffle and switched to linux.

    I almost made another convert who had bought a second, newer, ipod. But failed because amarok using libipoddevice couldn’t update a 6g ipod’s database :(.

    Keep up the good work. I am looking forward to seeing amarok using podsleuth.

Comments are closed.