Present Perfect

GStreamer

Tracking Heisenbugs this week. The first one was that after my return from holidays, GstPlay wasn't able to play back anything anymore. I didn't really look into it much until I really got annoyed and decided to read some logs.

The first problem was missing return value checking in the libraries, giving the Totem user no clue on what is going wrong. I added some error handling for these cases. On bugs like these it's best to work from the outside in, and first fix the bugs at the top of the stack. If you fix the underlying bugs, you forget about the toplevel bug that "the user doesn't know something is wrong".

The actual problem seemed to be osssink failing to negotiate, and after some digging I realized some code was added while I was away to autoprobe the allowed sample rates. The log seemed to indicate that it wasn't able to play back any sample rate, and from that point on everything failed.

I added some error signaling code for this condition. Only after testing again it suddenly worked. This was even more surprising. I wasn't able to reproduce it since, but I'm sure if anyone encounters it they'll at least get a nice error dialog. So now it's a matter of waiting until it pops up again for me.

Does serve as a reminder though that we really need to take more care in the stuff we commit after 0.8.0 - it is impossible to predict how other people's hardware will react to changes we make if they're less than trivial.

The second Heisenbug is one where playing our Matrix test clip and seeking a lot of times can trigger an error where it fails to negotiate. Dolphy and I thought it was a race, but it turns out it really isn't. It's another bug that gets exposed sometimes because of a race. Basically our plugin is somehow failing to cope with a resynchronisation after a seek. It looks like the mad library handles the resync correctly, but we probably mess up emptying the internal buffer somewhere. As a result, each seek, even in audio files, triggers a whole bunch of resynchronisation in a row as it's misreading header information and changing the sample rate quickly. Only in some random cases this fails and throws an error.

Mad documentation is very sparse and our plugin isn't exactly crystal clear either, so I'm spending some time reading the code and adding comments to figure out what exactly could be wrong. It doesn't help that I'm constantly distracted by other things to do as well.

One of those is thinking of the whole media playback/licensing issue. We're starting to see some solutions to that problem but they will all take time.

GNOME 2.6

I really want to use GNOME 2.6 as soon as possible, there are some enhancements that I'd like to use and there is code I want to test and fix. Over the last years I've changed and tweaked my cvs setup a little, and this time I made the last change I wanted to make. Instead of having the cvs checkouts and install locations under my user account, I decided to move it to /home/gnome and create a second test user. There are some things that really don't like having the same process from different locations for the same user at the same time running, so for those things it's better to run your cvs session as a different user.

So basically, I have jhbuild check out to /home/gnome/head/cvs and install to /home/gnome/head/prefix. I'll also be having a 2.6 jhbuild branch, in the same location, but with head changed to 2.6. Maybe I should write a short article on how I organize stuff and why, because a lot of people seem to run in various problems using cvs build tools and the resulting build.

Then I wanted to actually use it without interrupting with my regular X sessions, so I tried to use gdmflexiserver -n again, but it just crashes mysteriously on my Fedora box, bringing down the current X. After some searching and poking, it seems that this is a known bug (127780), and I pulled the fix from CVS and rebuilt the FC1 rpm - if you're experiencing the same problem, get this RPM and try it out.

So now my fake user is happily running GNOME head again, and I can finally fix some nautilus-media bugs again. And I get to recover about 5 GB of accumulated crap from my main user's gnome directories, including some stray patches I was going to still submit.

ssh key authentication

Some people gave me some tips. Apparently keychain is a daemon which allows you to authenticate only once per bootup, not once per session. Also, You don't really need the two files I created on Fedora Core; your X session is already run inside ssh-agent by default, and you can just add ssh-add to gnome-session-properties and you get a nicer, nonblocking dialog for your passphrase. Even better ! Thanks.

Life

Saw a poster this week for a great music festival at the end of May in the middle of Barcelona ! Beside Wilco, PJ Harvey and Elbow, the Pixies are playing ! I'll get to see them before all of my undoubtly jealous Belgian friends :) Too bad I have to be in Belgium the first day of the festival for my dad's thesis/graduation/professor thing, but as long as I can see the Pixies, I'll be fine.

GStreamer Tracking Heisenbugs this week. The first one was that after my return from holidays, GstPlay wasn't able to play back anything anymore. I didn't really look into it much...