Getting annoyed with computer stuff

This morning I was doing a backup again, but had the same problem as I did yesterday morning. The backup was going super slow (weird, since the same backup yesterday evening to my other drive only took about three quarters of an hour).

I went on Mauser's comp for a bit and checked dpreview, canonrumors.com, nikonrumors.com, bythom.com, and luminous-landscape.com. I also looked into CRC checking, since I wanted some way to confirm that my backups are okay and none of the files have been corrupted. Likewise, if a file on my PC becomes corrupted, I would want to know so I can replace it with a valid file from the backup.

Eventually I gave up on the backup, and decided to stop it. This took ages until Synkron actually stopped, and then ages to shut my PC down (in the end I had the same problem as yesterday, and had to reset the PC). While I was waiting I read a bit of John Shaw's 'Close-ups in Nature'.

When I'd got the PC running again, I tried disabling AVG and PerfectDisk, as AVG did an update that required a restart recently, and I'd recently installed PerfectDisk 11 (though I had had a beta version of PerfectDisk 11 installed before with no problems). I thought that maybe these programs were causing Synkron to get messed up and go so slow. However, after disabling them and restarting, I found that a couple of AVG processes were still running, despite being disabled from startup in msconfig and the AVG services being changed to manual start in the Windows Services config.

The one I was particularly concerned about was avgrsa.exe, the AVG Resident Shield process (which I had disabled from the AVG interface since installing AVG). I thought that possibly this was scanning all files as they were being transferred to the backup drive, thus slowing it down immensely. So to disable it, I just renamed the avgrsa.exe file.

I restarted the PC again, and now the avgrs process wasn't running. I was kind of hoping I'd get an error message to say that avgrsa.exe couldn't be found, and give me some indication of how it was being started, but I didn't get any error message.

Next I checked to how to get Synkron to use a binary comparison, as info I'd found suggested that this should be able to detect corrupt files. However, I couldn't find the option anywhere, so I looked at the Synkron FAQ, and found that it only uses the most recently modified date for comparisons. I'm sure I remember Synkron having an option to compare by time only, compare binary only, or compare using time and binary. Maybe that was a different backup program.

I had a look at SyncBack SE, which is a backup program I've read a few people recommend, but I couldn't see if it supported binary comparison or not. So I decided to just give Beyond Compare a trial, since I knew that did a binary comparison.

I installed the Beyond Compare trial, and then ran a folder comparison. Interestingly, it picked up some files it said were different (but both had the same last modified date, so Synkron hadn't noticed the difference). What the actual difference was, I don't know. It was 2 TIFFs and a PSB. The TIFFs rendered previews on both my hard drive and the backup, and the PSB on my hd opened okay, so I decided there wouldn't be any harm in overwriting the backups.

I did a sync, but then after the sync the comparison still looked the same. I did a full refresh, but it was still the same. So I checked and found that you need to do a mirror sync instead of a sync sync. I did that, and it went okay, but then I couldn't 'safely remove hardware' to remove the backup drive, so I shut down.

I was expecting to have the same problem as before, with the computer being really slow until it gets to the 'Logging off' screen, then hanging there, but actually the computer did shut down properly.

I checked the metadata of some more photos from day 2 of Korea, then had lunch.

After lunch I geocoded some images that had got the wrong co-ordinates already geo-coded, but then when I came to check their metadata, I found that the Korean characters had got messed up. Weird since I didn't think Robogeo would change any data other than the GPS tags. According to the FAQ it sounds like it shouldn't be doing it either:

Is RoboGEO's EXIF and IPTC lossless?

Yes. When information is written to the EXIF or IPTC headers, none of the image data is lost and all of the existing comments are preserved.

So I sent an email to them to say it was messing up the description and tags with foreign characters.

Now I had to go back through the images I'd geo-coded with Robogeo today and yesterday (probably about 20), and correct the broken characters. Luckily Robogeo doesn't work with psb or psd files, so in most cases I could export the XMP from the psb/psd file and then import it into the messed up TIFF or JPGs.

It still took quite a while to correct though. I also found on my website some images that have been uploaded with 'faulty' tags, so I'm going to need to spend quite a while going through them, updating the website and the original images.

I received a reply from the guy who makes Robogeo, who said that Robogeo can't be messing up the XMP description and keywords as Robogeo doesn't change the XMP at all. I did a test using exiftool to dump the XMP from a file before geocoding with Robogeo, and then the same after geocoding the image with exiftool, and he was right, the XMP was still the same, with the Korean characters showing up correctly.

But when I checked the geocoded image in Adobe Bridge, the Korean characters were showing up as gobbledygook. So obviously the problem was with Adobe Bridge. I thought that there must be a character encoding tag somewhere that Robogeo is setting to something other than UTF-8, which is causing Bridge to use the wrong character encoding to decode the XMP.

So doing some googling, I found that there is an IPTC tag 'CodedCharacterSet', used to store the character encoding. I checked the original image, and the geocoded image, and found the original had an IPTC CodedCharacterSet of UTF8, while the geocoded image didn't have a IPTC CodedCharacterSet tag at all. I used exiftool to add the IPTC CodedCharacterSet tag to the geocoded image, and give it a value of UTF8. I then checked the image again in Adobe Bridge, and it now displayed the Korean characters in the XMP correctly.

So it seems that Bridge relies on the IPTC CodedCharacterSet tag to determine the character encoding of the metadata, and if there isn't one, then assumes a default encoding (probably latin-1). While this might be sensible for EXIF and IPTC (if Adobe also provided a way that you can change the default character encoding), XMP is always UTF-8. Adobe created XMP, so why can't they even follow their own standard?

I let the guy who makes Robogeo know, and I will file a bug report with Adobe.

In the afternoon I also went in the garden for a bit. I saw quite a few bees, but they would only stay at each flower for about a second, so not long enough to try and get a photo. I also saw some mating weavils, but after a few shots they decided to jump away, which made me jump.

In the evening I also watched an episode of Star Trek with Mauser and L, and watched some videos by the film studio that makes Mio Mao.


The weather today was sunny all day.

Food
Breakfast: Bowl of Strawberry Crisp Oat Cereal; Cup o' Tea.
Lunch: Sausage with Mayonnaise, Sliced Cherry Plum Tomatoes, Wensleydale Cheese, and Salad Sandwich; Satsuma; Rocky; Cup o' Tea; Bit of Easter Egg.
Afternoon snack: Small bowl of Mackie's Ice Cream; Cup o' Tea.
Dinner: Battered Fish Portion; Peas; Mashed Potato; Salt; Ground Black Pepper. Pudding was a Toasted Teacake. Coffee; Cream Egg.