POV.1 and Sony Vegas

I own both the POV.1 Helmet Camera and Sony Vegas 8 (Movie Studio). Now, one would think editing videos made by the helmet cam would be no problem with Vegas … For some stupid reason, Vegas won’t read the video part of Xvid encoded files.  It obviously isn’t because of missing codecs, since vlc has no problems playing the files. After a bit of digging in the internet I found 2 tools to help fix the problem. The first shows which codec is used in the .avi (and can help if your problem is “only” a missing codec). It is called gspot. The second tool is called AVI FourCC Code Changer.

The solution to the problem is to start up the FourCC changer, open the POV.1 video (or any other Xvid video), and change booth fields to DIVX, press “apply” and that was it. Now Vegas stops behaving like a dork and reads the files.

Programming follow up

I just noticed I never wrote a follow up about my script that periodically parses the official World of Warcraft statistics. Unsurprisingly I wrote a basic Web interface to access the stored data. Since I stopped actively playing Warcraft the project kinda faded off my “todo radar”. So it has been stuck on my development site for months -> http://dev.dopefish.de (not the only project stuck in development, my “Voice-Over-IP Audio Shoutbox” also grinded to a stop after I ran into a flash problem)

I’d say it is about 90% done, currently it monitors 450 guilds and more than 15.000 players each day. It works pretty good, better than I had hoped considering how unreliable the source of the data is. There are a few quirks left in the code that I will iron out the next week, then I will release it so that anyone interested in the code can use it. In retrospect it isn’t much more than a big Proof-of-Concept that can be useful for others planing on doing similar projects.

(E)DNS – Bind logging errors

Anyone that has upgraded Bind recently is probably wondering where all those EDNS error messages are suddenly coming from. Well, since I’d rather fix a problem than set up an ignore rule for tiger, I did some digging and found out this much:
EDNS is an extension to “normal” DNS and has been around for some time. The most often reason these error messages are triggered, is when a firewall decides to drop dns messages that it thinks are too big (> 512 bytes). If this is happening on “your end” than the best solution would be to simply fix the firewall. If this is happening on the other end, or if it is something more obscure like a Firewall blocking fragmented NAT packets, than you might be better off just disabling the logging for this situation. On my system /etc/bin/named.conf.local is included by named.conf (saves me any hassle when updating bind via the distributions packages since all my changes are in a separate file)

/etc/bind/named.conf.local
logging {
category lame-servers { null; };
category edns-disabled { null; };
};

This turns off logging for edns-disabled and lame-server messages. So you can concentrate on the more important logging messages 😉