Recording in FreeGuide

If you download the nightly builds of FreeGuide, you can try out the new recording functionality.

There is quite a bit to do before this is ready for release. There are several bugs in the TODO list and you have to create your own scripts at the moment to launch mplayer or whichever recording software you want to use.

When the release happens, we will incude scripts that are useful for common TV cards (actually, it’s beginning to look like mplayer will handle all this for us, so all we need is one script) and make it easy to set up, with a default setup that should work for most people out of the box. Or that’s the idea.

The good news is that Alex appears to be back and working on fixing the bugs, so the ever-receding horizon of the next release is somewhat less receding.

I’ve not quite managed to get it to actually record something yet, (mainly due to mplayer being extremely awkward) but it shoud work…

Over-engineering gone mad

Picture the scene: you are writing a Java application and you’re trying to do things right, so you use the java.util.logging code to do your logging. To create a logger you do this:

Logger log = Logger.getLogger( "name" );

Everything goes fine until you want to set the logging level from a command-line argument. You set the logging level like so:

log.setLevel( lev );

Where lev is, e.g. Level.FINE.

When you run your program, none of your log messages appear except the ones that appeared before (SEVERE, WARNING, INFO). Nothing appears to have changed.

You read some API docs, and find out that each Logger has a list of handlers. So you call getHandlers() on your Logger.

It doesn’t have any.

You take a breath.

You read some more, muttering about Sun engineers having spent too much time at university, and find out that there is a hierarchy of Loggers containing other Loggers.

You simultaneously wonder how that could be useful, and whether some stupid thing is happening here to do with that.

You try log.getParent() and find that it is not null. Eureka! You’ve got it now:

log.getParent().setLevel( lev );

You hastily recompile, palms sweaty with finally cracking a problem that should not have taken this long.

Nothing has changed. You still don’t get your log messages.

OK, that’s fine: you know about handlers now, so it’s a simple change – we’ll do this instead:

log.getParent().getHandlers()[0].setLevel( lev );

You recompile, trying not to get your hopes up.


You consider re-writing your application (which has been in development over 5 years) in any other language. You decide to try one more thing before giving up. What if you need to tell both the Logger and the handler what level to use? It would be pretty awkward, but not outside the realms of possibility.

log.getParent().setLevel( lev );
log.getParent().getHandlers()[0].setLevel( lev );

Not even very hopeful now, you recompile.


This is the moment where you go and find anyone who will understand (or failing that anyone at all) and tell them about it. They wipe the spittle from their faces and appear keen to leave.

You will not be defeated by this. You try every combination you can think of. You start looking into how to log a bug with Sun. You curse and curse again.

A very long time later, you know you should have given up, and you’re trying things just out of bloody-mindedness, and you stumble across this:

log.setLevel( lev );
log.getParent().setLevel( lev );
log.getParent().getHandlers()[0].setLevel( lev );

Yes, that’s right. To set the log level of the default logger in Java you have to learn about handlers and the logger hierarchy, and you have to set the level in three places.


You swear never to feel superior again when people start having “language wars” about which programming language is better. They are not all the same.

You engage in a relaxing pasttime, such travelling to Sun’s development centre and punching the person who “designed” that interface in the face.