Mono, DBus, and Hal – Help

Here’s the story. I’m trying to hook into Hal to detect when a device (specifically an iPod) is attached. I can do this in C, Perl, and Python, but I can’t get the C# version to work.

The code should be fairly straightforward. I’m using the definition of HalManager from hal-sharp, which as far as I know is current to the latest Hal spec. DBus 0.23, which is working just fine. My next step is to do some debugging in dbus-sharp and see if I can identify what’s failing and why, but maybe someone has already run into this. I can’t be the only person trying to access the Hal Manager via C#.

The exception:

Unhandled Exception: DBus.DBusException: Disconnected prior to receiving a reply
in <0x0015a> DBus.Message:SendWithReplyAndBlock ()
in <0x0007c> HalManager.Proxy:GetAllDevices ()
in <0x00087> podlet:Main (string[])

The code:

[code]
// Compile with: mcs -target:exe -out:”podlet.exe” -pkg:gtk-sharp -pkg:dbus-sharp ./Main.cs ./AssemblyInfo.cs
using System;
using System.Collections;
using Gtk;
using DBus;

[Interface(“org.freedesktop.Hal.Manager”)]
public class HalManager
{
public delegate void DeviceAddedHandler(string udi);
[Signal]
public event DeviceAddedHandler DeviceAdded;

public delegate void DeviceRemovedHandler(string udi);
[Signal]
public event DeviceRemovedHandler DeviceRemoved;

public delegate void NewCapabilityHandler(string udi, string capability);
[Signal]
public event NewCapabilityHandler NewCapability;

[Method]
public virtual string[] GetAllDevices()
{
return null;
}

[Method]
public virtual bool DeviceExists(string udi)
{
return false;
}

[Method]
public virtual string[] FindDeviceStringMatch(string key, string value)
{
return null;
}

[Method]
public virtual string[] FindDeviceByCapability(string capability)
{
return null;
}
}

class podlet
{
public static void Main(string[] args)
{
Connection connection;
connection = Bus.GetSystemBus();
Service service = Service.Get(connection, “org.freedesktop.Hal”);

HalManager manager = (HalManager)service.GetObject (typeof(HalManager),
“org.freedesktop.Hal.Manager”);

foreach (string device in manager.GetAllDevices()) {
System.Console.WriteLine(device);
}
}
}
[/code]

GStreamer, GLib, and Gnome-VFS oh my

I’m getting closer to the 0.1 release of EMP. I finished writing the code to import music this morning. There are some optimizations I’d like to make (mostly, spinning off the reading metadata off to a worker thread), but right now it takes just over six seconds to scan and import 248 songs. Some of the speed may be the drive in my laptop, and a large chunk the reading of metadata. It’s quick enough for the 0.1 release though. My next step is to integrate this with the UI, and then it’s time to finish the main player UI and get this first release out the door. I’m aiming to have 0.1 released around the turning of the new year.

The import code was pretty fun to write. One of the complaints I (and others) had about other music players, especially those using GStreamer, is that it tends to be slow importing, or hang trying to import. With that in mind, I’ve taken a two-step approach to music detection. First, I use Gnome-VFS to check the mime type of a file. I ignore anything that isn’t “audio/*”, then feed the file through GStreamer’s typefinder and checking its found mime type against a static list of playable mime types (essentially ogg, mp3, flac, mod, and wav). Only then do I add a song to the library. From my testing, it does a good job of only adding audio and not hanging on miscellaneous files (Flash seems to be a big problem for GStreamer).

EMP is now in my CVS, and the import code is currently living in test/import.c, if anyone wants to see an example of recursively scanning directories and GStreamer.

blogspyder.com

I like building search engines. It’s been my job for the past five years. Unfortunately, our focus has shifted to less search engine and more ad distributor. I still experiment in my spare time, and my latest creation is blogspyder.

Last weekend Dena and I stopped at the grocery store after seeing The Incredibles. As we walked through the isles, the idea of applying my search engine knowledge to blogs. Google does a good job of indexing blogs (they seem to hit mine daily) but I don’t care for the intermingled results you get in their text index. I’d prefer to have blogs searchable seperate from everything else.

I’m also interested in the relationship defined between blogs. Say I link to Jorge and Dena. There’s a relationship between me and Jorge, and me and Dena. Now say that Jorge links to Dena. There’s now a new relationship between Jorge and Dena, which says something (I don’t know what yet) between me and them.

I’m also working on some algorhythms that will identify common topics, so you could select to browse the technical or political categories and see relevant blogs. It will also identify trends on a timeline, so that as data is indexed, hot topics can be highlighted in realtime.

Blogs are the current big thing, it seems, even though they’ve been around for a long time. I don’t think that’s going to change much as time goes on and I think we need better ways to find the content we’re interested in reading. Maybe this will be one of them.

gterrar

I wrote this several months back, but apparently didn’t blog about it. Today, RML blogged about the applet he wrote to do the same thing. I like the applet concept — a lot. What would be really cool would be a merge of RMLs applet with my gterrar. I’d love to have the color-coded panel applet, but click on it to get the floating terror display.

The original version of gterrar is still online. I haven’t touched it in a while, but it still works.

P.S. Props to greenfly, who wrote the original gterrar in perl.

Where does the time go?

This past week has been pretty hectic. I’ve spent most of my time working on a ‘Related Search’ engine for work. Basically, if someone searches for ‘cat’, it can suggest alternate searches, such as ‘cat food’, ‘cat toys’, ‘pet care’, etc. It’s a fairly large project — one that I’ve been working on in one shape or form for a year now. My original prototype worked with only a limited subset of data, but worked fairly well. I expect that this new and improved system will work orders of magnitude better.

It’s kind of silly the the way deadlines work. I was supposed to deliver implementation documentation before the system was assembled. I managed to delay that until, you know, we had decided on how we were going to implement it. Then there’s the actual act of deployment; it would be really nice if I had the hardware to deploy it on. Right now, it’s all running off of a single three year old development server with 512M of ram. With a database into the tens of gigabytes (and growing rapidly), this poor server is straining under the load. I just know that the question of when we can actually start selling this service and I’m going to have a minor battle on my hands to get the necessary hardware.

At least I have one thing to look forward to: five days til election day. I hope that there is a clear cut winner by the end of the day. I’m afraid of what will happen if this drags out like last year. I enjoy watching news and debating politics but there’s only so much partisan bickering I can take before I want to move to a shack in Montana and start a letter-writing campaign.

podlet: syncronization and Gnome2::VFS

I’m making good progress on podlet. I started working on the syncronization logic. There are a few important things to take into consideration before copying files to the iPod:

  • What files need to be copied?
  • Does the target have enough free space?
  • Do we need to prepare the music before copying it?

ped recursively through my music folder, I found a few non-music items that I wouldn’t want to sync. I need to figure out a way to limit what files get syncronized. I can check file extention or mime type (assuming that checking the mime type does more than look at the extension). I also want to only syncronize music formats that the iPod support.

Checking that there is enough is critical, and there should be some kind of resolution progress if I’m trying to sync more data than the device can hold. I’m considering some kind of ‘conflict resolution’ dialog, so that if I can’t copy all of the music, the user can opt to not transfer files to the iPod, or let them open the iPod browser to remove some files.

Lastly, is there any processing we need to do on the file before we transfer it. This is more of a future enhancement (once the gstreamer-perl bindings are ready). Say you have an iPod mini that you use while jogging. For this, you’re more concerned with the quantity of music, rather than the quality. This option would let you to downgrade your music to a different format/bitrate so that you can fit more on a device.

I’ve found the Gnome2::VFS call to get the free space on the device. Once I decide on how check the file type (and I’m leaning towards mime type), I can calculate the needed space and then handle resolving any conflicts.

I’m working towards a 0.10 release sometime in the next week or so. I want to get the basics of syncronization working, so that I can get a few people to test that out while I start to add the bells and whistles like the iPod browser.

podlet: auto-detection done

I finished integrating the code to auto-detect the iPod via HAL/Gnome2::VFS. I still need to test the VFS cleanup – making sure there are no leaks and whatnot. I also need to tackle automake/autoconf, or whatever it is that supplies ./configure and such. I’m not sure how I’m going to handle dependancies yet. libgnome2-vfs-perl in sid isn’t new enough. The latest version, along with Gnome 2.8, still sits in experimental.

I think for now I’ll worry about the ./configure stuff and make a note in the install file. It’s fairly easy to install the latest libgnome2-vfs-perl and it shouldn’t impact anything else on the system.

podlet: iPod detection

I finished writing the iPod auto-detection code tonight, which means i’m almost ready to move on to syncronization.

This was a fun bit of code to work on. It was my first time working with Gnome-VFS. It took a little while to get the perl binding to work. That ended up being an old version of the library in Debian. Once I installed the latest version, it worked like a charm.


stone@moradin:~/src/internal/podlet/tests$ ./ipod_detect.pl
iPod detected at /dev/sda2

Essentially, it gets a list of all mounted volumes and iterates through them, checking for the existance of the iTunesDB on the volume. When it finds the file, we’ve found the iPod. I have to add a couple signals to detect insertion and removable of volumes and I can call this piece done.

podlet – preferences

I spent my lunch figuring out how to use Glade2 and Perl. Gtk2::GladeXML makes it painfully easy to integrate Glade components.

I have a big chunk of the framework in place and I’ve started attaching widgets. First on the plate is the preferences dialog. The first tab sets the stage about how we’ll recognize and communicate with the iPod. Automatic mounting, or discovery, will use DBUS and HAL to know when the iPod is attached and mounted. Manual will simply probe the mount point and wait for the iPod to be mounted. There are two supported formats – iTunes and GNUPod. GNUPod is great if you only use your iPod with Linux, but if you ever want to sync between Windows, Linux, and a Mac, stick with the iTunes format.

podlet preferences
Gtk2 pretty. Glade2 rocks.

podlet

I’ve talked about working on iPod support for Rhythmbox, and iPod support in general under Linux. I did do some work with Rhythmbox, but in the end I faltered and gave up on it. The future of Rhythmbox isn’t clear to me, and from the start I had qualms about writing application-centric support for something like the iPod. After much internal debate, I’ve decided to take a fork in the road.

I’ve been using Perl quite a bit lately. Then I discovered GNUpod. The wheels began to turn. I started to play with gtk2-perl. More cogs began to spin.

Thus was born podlet, a perl application that uses Gtk2::TrayIcon (which follows the freedesktop.org System Tray specification). In essence, it will be a complete syncronization tool, not just for music but also contacts, calendar, and tasks (not limited to, but including this bounty).

podlet
Proposed look of podlet, sitting in the Notification Area. The icon changes based on the current status – idle, syncronizing, or disconnected.

One- and two-way syncronization of music. I use my iPod with my laptop, but I don’t want to keep a full backup of it on there. One-way syncronization would let me syncronize music to the iPod without filling my hard drive. Two-way syncronization, as you would expect, would make sure that your library on your iPod is a mirror of that on your computer.

Calendar, contact, and task syncronization should work with any application you choose to use. There will be a plugin system to support various sources for this PIM data, so you can sync your iPod with Evolution, vcards, Thunderbird, Sunbird, etc.

In the end, I think podlet will make a pretty decent little syncronization tool. I’ve thrown my work into CVS and started to hack out the core of what needs to be done. I’ve also started to play with Glade. There will be a preferences dialog to manage podlet’s settings, and possibly a druid to be run on first run to walk the user through setting up syncronization.