Archive for August, 2009

Houdah Geo – Excellent Support

Saturday, August 29th, 2009

As I indicated in my previous post, I’ve been having some problems with geotagging photographs which use Canon’s CRW format. This format is not able to be written with the usual exiftools but I was looking for a way of at least getting GPS data associated with the photograph into iPhoto. HoudahGeo seemed like it might do this, but I was having problems with it not matching up the time correctly. I posted a report on the program’s forum and got a reply from the author very quickly and continued to exchange information with him (including last Sunday, when I certainly did not expect to get a quick reply). Any after sending some samples to the developer, he found the problem and it is corrected in his latest beta version. I’m always impressed with developers who are so responsive to users. Many thanks to Pierre Bernard!

Geotagging photographs

Thursday, August 20th, 2009

Since Apple’s iPhoto introduced “Places”, I’ve become more and more interested in geotagging photographs. Earlier this year I bought a handheld Garmin Etrex Legend HCx GPS receiver which has proved useful for helping guide me on cycle rides, walks and even in the car given the purchase of suitable maps. It also maintains a tracklog and so can be used to work with software that links the time on photographs to the time on a tracklog to associate a latitude and longitude with a photograph. EXIF data has space for location data so it is, in principle, a fairly simple process to import track logs, match the times with photographs and insert appropriate EXIF data. In practice there are a few things that one needs to take care of such as keeping the time on the camera accurate (or at least knowing the divergence). In my case I try to take a photograph of the Garmin screen in one of the modes where the Garmin shows hours, minutes and seconds then one can always look at the EXIF data in the photograph and compare it with what is displayed on the Garmin in the photograph.

Several pieces of software perform this task well. GPSPhotoLinker from Early Innovations is donation-ware that performs an excellent job. Early Innovations also has a paid for application, PhotoLinker which offers more features. HoudahGeo is another paid for app which has a natural work flow and can operate with iPhoto and Aperture libraries (otherwise one has to do the geotagging as a separate step before importing into the library).

All has worked well for me with photos from my point and shoot Canon A720IS, but I also have a (now rather elderly) Canon EOS 300D. With this camera I usually shoot raw which uses Canon’s CRW format. This doesn’t work with GPSPhotoLinker and has shown some problems with HoudahGeo — although the author of HoudahGeo is very responsive so I’m hoping for a way forward.

Over the past year I’ve become quite excited about both geotagging, and generally tagging photographs with information on their content, if only because like many other people there are boxes of photographs I’ve inherited which are pictures of relations but with no indication of who, when or where the image was taken.

More Gnucash struggles

Wednesday, August 12th, 2009

I was going to write a post on why I like Gnucash and how it seems incredibly robust, but I’m not entirely sure that I can convincingly write such a post now. In addition to the previously reported problems, I noticed today that I had an enormous imbalance. It looks like a large proportion of the transactions recorded in 2001 have lost their links to their income and expense accounts (categories in the parlance of many other personal finance programs). There are only 16 problem entries since then, some of which I remember causing difficulties when they were entered. I assume that the update and file format enhancements have exposed these problems.

I think I’m not going to attempt to repair all of the 2001 entries and just “close the books” on that year. Arguably I should have done this a long time ago, but until recently one needed to do that by hand in gnucash whereas I believe there is functionality to support that now. The remaining transactions I think can be repaired fairly easily.

From the fact that there are very few more recent problematic transactions, I believe that the gnucash stability has probably improved significantly over the last few years, but I’m certainly not as robust a defender of it as I was a few weeks ago. However, the whole issue of consistency is one of the major criteria that I shall be using in my comparison of personal finance applications.

Gnucash on Mac OS X

Monday, August 10th, 2009

On linux I’ve been a long-time user of the Gnucash program. As a personal and small business accounting program I’ve found it excellent (not that I’ve used it for a small business, but it seems to have many of the features that would be needed). As a personal accounting programme it certainly manages bank accounts, investments and portfolios, multiple currencies and uses double entry book-keeping throughout. While not trivial to start using, it certainly isn’t particularly difficult and I’ve found it extremely reliable.

When I started using Mac computers, I still had a small linux box that amongst other things was used (typically remotely) for using gnucash. In early 2007 when I started commuting between countries for work, I bought a MacBook and decided I needed to take gnucash with me. After a fair mount of difficulty but thanks to some pretty useful comments on the internet, I was able to use Fink to compile gnucash and run it on my MacBook and I’ve been using that version until this last week. It wasn’t perfect — I was never able to get the scripts to get online quotes to work (although they worked fine on my linux machine). By now it was a build that was over two years old (a version 2.0 of Gnucash).

Even in linux circles, gnucash has a reputation as something of a “dependency hell”. It just needs so much other stuff to compile that it isn’t funny, and some of which it is difficult to understand why it is a dependency. However, on most linux systems, users can take advantage of the package manager on their system to pull in all the relevant binary packages and have the working version that was compiled by their distribution. I have used SuSE for a number of years, although switched to openSUSE a few years ago. On my linux box I’d been running openSUSE 10.3 which had a version of gnucash in the 2.2 series.

I’ve been running one set of accounts on my MacBook with the fink compiled gnucash 2.0 for the last 30 months, while running a second set of accounts on my linux machine. The linux machine recently had problems which meant I needed to manage the gnucash account on that machine on my MacBook. Unfortunately there had been changes to the data format between 2.0 and 2.2 which meant that gnucash 2.0 couldn’t open gnucash 2.2 files. (Gnucash does store its data in a compressed XML file which at least means if all else fails one can get into it.)

For some time I’d been following various internet pages with instructions about compiling gnucash with Quartz on Mac OS X rather than using X11, and had spent some time following the instructions about using GTK-OSX which effectively provides an implementation of GTK2 via the Quartz graphics on Mac OS X. For me, following these instruction has always failed pretty close to the point where I was ready to compile gnucash. I’d started with enthusiasm in early 2009 but had given up.

Having noticed that it was now possible to build gnucash almost automatically on OS X using MacPorts, that seemed the easiest route.

My experience was not exactly plain sailing. For some reason one of the dependencies brought in via MacPorts is goffice which wouldn’t compile although I was fortunate to find a patch at 
http://lists.macosforge.org/pipermail/macports-users/attachments/20090520/03dbddc6/attachment.obj. The slightly annoying thing about this is that this appears to have been a a problem that has been extant for at least a couple of months. With a program with so many dependencies, it is just so easy for something to get broken.

This enabled me to complete the compilation. On attempting to run, I got various messages about not being able to read configuration files which pointed to problems with a component called “dbus”. Again, my problem was solved by various (somewhat confusing) sources. Essentially you don’t follow the instructions that are produced when dbus is built, but do something slightly different. I’ve put it on the discussion page on the gnucash MacOSX/MacPortsDetail site. Again this seems to be a fairly long established problem with ports to Mac OS X.

After all this, which had taken a few days, I was able to successfully launch gnucash 2.2.9 built on my machine on 4th August 2009. Great! However, another problem loomed. It would open both my gnucash files and worked with the gnucash 2.2 file from my linux machine. However although it would open the gnucash 2.0 file that I’d been using for two and a half years on my MacBook, every time I came to save it there would be a crash and the resulting file would be unopenable. At this point I feared having to work forever with my old fink-compiled version for my finances and my new compiled version for my partner’s finances.

The next step in the installment was a mad day when I decided to use a windows PC with an external drive and install the latest version of openSuSE on the external drive. My plan was that, although not convenient, I should be able to run gnucash on that using the openSuse distribution. I’ve done this previously and expected it to work — possibly with a few hitches. The installation was fine although I had to help it with the rebooting (probably because of the external drive) and it took only about an hour. I was able to install gnucash on it and amazingly it had no problems reading my old gnucash 2.0 file writing it out and reading it again. Furthermore when shifting the file back to my MacBook, it also could read and write it — although still complaining about problems with not knowing some currencies. There were some other hiccups with the linux installation that I might get around to writing up.

I am now trying to do two things:
1) check that this gnucash is working reliably on the MacBook (which is not quite true) and 2) look at alternative MacOS X programs that I could migrate to.

I’ve discovered in the last day or two that the gnucash “find” facility isn’t working. It brings up the dialog box but one can’t type in a string to find.

After the struggles of the last fortnight I just don’t want to go through another building process although I notice there is another alternative build on the MacOSX/Quartz — GnuCash page but I’ve really lost the enthusiasm to try.

I have started looking at some alternative programs and have purchased iBank, but I’m now not at all convinced that it is the right choice.

I am going to try to put together a comparison of personal financial software for the Mac and would welcome any comments or ideas.

MacBook Problem

Sunday, August 2nd, 2009

This morning my MacBook just turned off (with a click when using it). It was running on battery power at the time (about 30–40%). It wouldn’t restart again. I guessed that it could be the power management system, but visited Troubleshooting a MacBook, MacBook Air or MacBook Pro that won’t turn on and worked through the steps there. After completing Step 8 (out of 10) — “Reset the SMC” was able to re-insert the battery, press the button and hear the familiar start-up chime.

Curiously once started up, got a message that permission was incorrect on an EyeTv element (I use Elgato’s EyeTv with an Elgato Hybrid USB tuner). I’ve never seen such a message before from the system on start up. I let it fix that.

I ran a disc check using Disk Utility and a Repair Permissions also from Disk Utility. Repiar Permissions reported a very large number of incorrect permissions that it repaired — many on QuickTime and FrontRow but also on other stuff as well. I would have done a repair permissions only a couple of days ago as a precursor to doing my weekly SuperDuper! backup, so this is a little surprising.

Hope that everything is going to be good now.

Well, it wasn’t — sometime later this morning the machine became completely unresponsive and the light on the magsafe connector was out, although being plugged in. This time a forced stop and restart using the power button did work. Again a Disk utility check and repair permissions showed a vast number of permission problems.