I wanted to display the current song playing on my desktop using GeekTools. I found some info on accomplishing this with AppleScript here. Pretty straightforward, but their script is clever in that I think it only runs if iTunes is running. I modified the script a bit, here’s what I have:

tell application "System Events"
	set powerCheck to ((application processes whose (name is equal to "iTunes")) count)
	if powerCheck = 0 then
		return ""
	end if
end tell
tell application "iTunes"
	try
		set playerstate to (get player state)
	end try
	if playerstate = stopped then
		return "Stopped"
	end if
	set trackID to the current track
	set trackName to the name of trackID
	set artistName to the artist of trackID
	set albumName to the album of trackID
	set totalData to artistName & "
" & albumName & "
" & trackName
	return totalData
end tell

All the Internet sources I read say coffee is best brewed at 195F – 205F. This fancy new Keurig cup brewer I got maxes out at 192F, the “optimal temperature” according to them. Most home drip makers struggle to get to 190F.

Some basic graphs of my house’s energy usage. Linear and radial view of the month of January; average and samples

 

The Thinner netlabel included JPG images for all their albums but didn’t embed them in the MP3 files. Consequently iTunes can’t find them. Dealing with id3 is a bit of a black art, the tools and formats are varied and poorly documented. But I think this works and is safe:

eyeD3 –to-v2.3 –add-image thn018.jpg:FRONT_COVER *.mp3

That adds thn018jpg as a front cover to all MP3s in the current directory. The converstion to 2.3 is necessary; eyeD3 can read but not write the 2.2 tags that are in the early Thinner releases. Note that this will add a second image if one already exists. Only safe to run once :-P

Getting clever:

#!/bin/bash
for d in thn*; do
 JPG=$d/$d.jpg
 if [ ! -f "$JPG" ]; then
 echo "$JPG not found, skipping directory"
 continue
 fi

eyeD3 --to-v2.3 --add-image $JPG:FRONT_COVER $d/*.mp3 > /dev/null
done

Sad fact: iTunes won’t display GIFs, only JPGs.

MacOS’ version of “top” reports a weird process state; “stuck”. According to top many of my processes are “stuck” including Postgres while it’s completing a table scan, and Growl, and many Google Chrome subprocesses. But checking the top sources indicates “Stuck” really means TH_STATE_UNINTERRUPTIBLE, which I believe is what ps reports as process state “U”. I’m guessing this is what Linux calls “D” for “Device Wait”. In which case, in most cases the process is fine, it’s waiting for some I/O to complete.

While I’m here, is there any good reason MacOS top defaults to sorting by process ID? I have to type “ocpu” every time to get it to sort by cpu.

 

When my old server died I had some data in Postgres. I don’t think it was anything important but I can’t really be sure, I’d like to recover it. All I have are the binary files Postgres stores its data in. Turns out recovering from those sucks. Lesson learned: if you care about recovering your data, back it up into a SQL dump.

Postgres makes no effort to make its binary files compatible between versions. A 9.0 database can’t be used in a 9.1 install; when you upgrade, you have to run a funky recovery tool which dumps the 9.0 db and imports it to 9.1. A 9.0 database on a 32 bit machine can’t be imported into 9.0 built for a 64 bit machine, either. I’ve also seen problems in the past trying to work with data from a PostGIS database in a non-PostGIS install. I’m sure this format flexibility makes it easier to build a fast database engine, but it sure makes data recovery difficult.

I tried building 9.0 sources on my amd64 box and running it. That was easy enough, although setting up users and permissions is a bit finicky when installing by hand. But the DB was generated on an i386 box (32 bit) so it won’t load. At least it failed quickly, “FATAL:  incorrect checksum in control file”. Then I started looking in to cross-compiling and realized the last thing I want is to set up a whole separate build toolchain. (A quick try with the linux32 command didn’t work.)

So screw it, what was I really storing in Postgres anyway? Not much, I did a quick test to see:

find . -type f -name \*py | xargs egrep -i ‘psycopg2|postgres’

Only one Python program I wrote even imports the Postgres driver. And I can recover that data from original sources. I think I have some geodata I imported with shp2pgsql, too, but I can redo all that. So I give up on recovering data.

Cross-compiling

Maybe I gave up too fast. Building a 32 bit version of Postgres on Ubuntu was as easy as

./configure CC=’gcc -m32′ –prefix=/tmp/pgsql90i386  –without-readline –without-libz

(there’s probably 32 bit versions of readline and libz, but I don’t really need them). Building a server this way, my amd64 machine can load the database binaries generated on the i386 machine. I had no idea the 64 bit Linux distributions could build 32 bit code so easily.

And it works! “psql -l” to find what databases were there, then “pg_dump database” to get the data out, then “psql” to get the data back into my 9.1 database. Yay!

Backups

Lesson learned, I’m now doing some simple nightly SQL backups of my databases. There are fancy ways to do this, I’m going very simple:

DEST=/mnt/sdb1/BACKUPS/postgres

set -eu
renice 10 $$ > /dev/null

pg_dumpall --lock-wait-timeout=$[5*60*1000] | gzip -9 >| $DEST/dumpall-sql.gz

 

The graph below is a nice illustration of how a disk gets slower as it fills up and the OS starts using the slower cylinders. (At the inside of the platter). I was bulk copying 500G of stuff to sdb, a new disk, around Sun 00:00.

I’m trying to back up my machine in a datacenter to my home server, using rsnapshot. The home machine is behind a firewall and pretty secure but I don’t want to be stupid about it. The remote machine should be secure, but is not firewalled. (OTOH both run ssh and http, so the attack surface is about the same). I found two useful guides for doing remote backups securely: one, two.

My final config is a pastiche of the two. Here’s the concept behind what I did. Backups run as root on the backup server and as a special-purpose user on the client being backed up (who can sudo to root to run rsync).

• On the backup server, tell rsnapshot to backup a remote host via rsync.
• On the backup client, create a new user who has no special privileges
• Set up ssh keys (with no passphrase) so that root on the backup server can login as the backup user on the client. Restrict that ssh key to only be allowed to run an rsync frontend.
• On the client, give the backup user the right to sudo to root but only to run /usr/bin/rsync.

I feel pretty good about the security; the user would have to steal my private key from the backup server to access the client, and even then they’re only restricted to run rsync. However that rsync is run as root and I’m sure could pretty easily escalate by, say, overwriting /etc/sudoers.

It’d be more secure to run backups on the remote client as some user other than root. But I want to back up files only root can read, so I’m kind of stuck.

 

Over on the Sonos forums I asked about which ID3v2 tags the Sonos uses. I got a great reply that seems to be correct, reproducing it here. It’s from Rick Parsons aka “renowden”.

TIT2 [Title/songname/content description] – commonly called Track

On the Sonos this is called “Track” and is available in an index and on the controller screen when the track is playing.

TPE2 [Band/orchestra/accompaniment] – commonly called Album Artist

On the Sonos this is called “Artist” as an index but does not appear on the display at all when a track is playing.

TPE1 [Lead performers(s)/soloist(s)] – commonly called Artist.

On the Sonos this is called “Contributing Artist” as an index. It shown on the display as “Artist” when a track is playing. In theory multiple artists can be put in this field (separated by a “/” but some tag editors show it as a “;”). In practice the Sonos sometimes shows only the last one on the list. I haven’t been able to determine why.

TALB [Album/movie/show title] – commonly called Album

On the Sonos this is used as an index. It also shows on the display when a track is playing.

TRCK [Track number/position in set]

This is not displayed anywhere but is used to determine the track order in albums.

TCOM [Composer(s)]

This is used as an index but does not show on the display during playback.

TCON [Content type] – commonly called Genre.

This is used as an index but does not show on the display during playback.

COMM [Comments] {iTunNORM}

This is written by iTunes and is discussed at length elsewhere. In summary it can, in the right conditions, be used to level the volume of playback.

There is another tag written by Windows media Player which performs a similar function to iTunNORM but I haven’t discovered what it is.

Still wrangling the metadata on my music library. ReadyToPlay did a good job on the rip and categorized all music into a relatively small set of Genres. I’m taking this as canonical for now.

Avant-Garde • Ballet • Blues • Chamber Music • Choral • Christmas • Comedy\Spoken • Concerto • Country • Electronica • Folk • Jazz • Keyboard • Latin • New Age • Opera • Orchestral • R&B • Rap • Reggae • Rock • Soundtrack • Spoken Word • Symphonic • Vocal Music • World

Well, not entirely canonical; I’ll probably unify a couple of these. Also the classical feels wrong to me: I couldn’t tell you Orchestral from Symphonic. I’d prefer to break it down by Musical era: Early, Baroque, Classical, Romantic, Modern. Of course those are ambiguous too.

One thing that’s really annoying in my metadata; music is indexed by the composer’s first name. So Tchaikovsky is filed under “P”, for “Pyotr Il’yich Tchaikovsky”. It’s a bit of a trivia game.