M3

The iHome iW1 AirPlay speaker was released October 2011 and, barring recent entries seen at CES 2012, strikes a good balance between quality and price: $299 for a good-looking design, iPod-mode and AirPlay-mode speakers, and volume loud enough to fill small and medium-sized rooms.

I’m not a professional reviewer, so I’ll direct you to other reviews for photos, videos, and the like. Here are my impressions:

• Perhaps most important of all, as of iOS 5.0.1, the iPhone 4S does not work with this speaker. iOS 5.0.1 running on an iPad or 3GS works fine, as does AirPlay streaming from iTunes. iHome reports that Apple is aware of the issue and working on a fix. I have no word as to whether the recently released iOS 5.1 beta 3 addresses this.
• WiFi setup is accomplished by plugging an iOS device, running a free iHome setup app from the App Store, into the speaker. The app is well-designed and easy to use, and although I wouldn’t want an LCD panel anywhere on this thing, it’s still yet another app I’ll have to keep on my phone that will be used, literally, only for a few minutes.
• It’s fallen off WiFi twice so far. Nothing terrible: I’ve used maybe twenty hours total across two weeks so far, perhaps spanning seven or so separate occasions. It does not fall off WiFi while I’m using it, but I have sat down on a new day and noticed it is unavailable on my AirPlay menu and the WiFi light flashing. Power cycling the device fixes this. It is in an area of good WiFi coverage, but I do have iPhone 4Ss on my network. No idea if this affects anything, nor can I confirm it is the iHome and not my WiFi network. I’m running off a latest generation Apple Time Capsule, 802.11n.
• The touch-sensitive panel at the top is neat, though I find myself tapping the power button once to turn it off, only to have this activate the touch sensor, forcing me to touch it a second time to turn the device off. Admittedly, however, you don’t have to turn the device off – you can merely leave it alone and it will run fine. The touch panel is a bit annoying when you merely want to wipe the dust off the top – yes, it thinks you’re pressing all the controls.
• There are two power buttons, but I think there’s a good reason for this. Part of the appeal of the iHome is it’s internal battery, allowing you to pick up the speaker and carry it to a needed room, returning it to its dock later on: a power button on the top, which is really a sleep/wake-type power button, and a real power button on the back. I believe the power button on the back is merely if you intend on traveling far with the iHome and don’t want the battery drained while in transit. (Docking is painless – no hard connectors, merely contact is required, and the curve of the base makes it easy to set the speaker down in “about” the right place and have everything line up correctly.)
• It has two modes: WiFi (for AirPlay) and iPod mode, for old-fashioned docking. It seems to switch on the fly though, so you never have to worry about this control.
• The thing is fairly loud: I set it up in a relatively small bedroom, and sit about ten feet from it, and have to keep my iTunes volume turned down to about 20%. It’s plenty loud, even for a large living room. The fidelity is fine, but dropping $299 on a pair of headphones would certainly give you better quality. Nothing to complain about, but I’ll stick with headphones for close listening.
• The device currently has no firmware updates but does support it via copying the firmware on a USB stick and plugging it in the back.
• No idea what happens to the battery if you leave it plugged in all the time: presumably it’s a lithium-ion battery, so I’m guessing the battery just slowly goes with time through lack of use.
• It includes a remote. I never touch the thing given that I’m interested in AirPlay.

Bottom line: I wanted a good-looking table-top AirPlay speaker, and this fits the bill and fills out it’s $299 price tag nicely. If you’re in no hurry, check out the AirPlay devices announced at CES 2012 as well.

I’ve long appreciated this page by Troy Johnson, detailing the process of using cron, ssh, and rsync to create free, encrypted, and automated backups of remote systems. I use it to make personal backups of remote servers, just in case every line of backup defense at my hosting group fails.

But I could never get it to work on OS X. If you’ve ever set up more than a modestly simple cron job, you’ll know the difference in environment variables between your normal session and cron is enough to frustrate any UNIX denizen.

Troy’s method, specifically, seemed not to work with my SSH private keys. The command I set up ran beautifully as my user, but would always fail under cron.

I haven’t researched the particulars as to why, but private key access is apparently handled through a separate daemon under which a cron+ssh would not normally have access to. Simply add the following (tested under OS X Lion) at the start of your script to fix your environment variables and resolve this issue:

declare -x SSH_AUTH_SOCK=$( find /tmp/launch-*/Listeners -user your_user -type s | head -1 )

Replacing your_user with your username.

Here’s the entirety of my setup:

crontab:
@daily /Users/your_user/the_backup_script.sh

the_backup_script.sh:
#!/bin/bash

echo "Backing up /the/directory"
$RSYNC -az -e "$SSH -i $KEY" $RUSER@$RHOST:/the/directory /Users/your_user/Backups/remotehost-server/the/directory

Radiation City played at Luigi’s Fun Garden in Sacramento last night. They sounded pretty good and were nice people.

Below are two recordings from that show. I’m curious if anyone can tell me the song titles.

Be sure to buy their album if you like what you hear.

Tech Notes: Recorded on an iPhone 4S. Non-aggressive noise removal + multiband compressor applied.

Apple IDs are problematic. With the number of Apple IDs growing past 160 million, Apple has to do something. What’s wrong, exactly?

• Inability to rename Apple IDs unable some circumstances
• Inability to merge Apple IDs
• Apple IDs have had alternative backends that are troublesome (e.g. @aol.com-based)

Coming home for Thanksgiving, I upgraded my mother’s iPad to use iCloud. It turns out you have to change your Apple ID to a valid e-mail address. Good idea. Unfortunately, her only e-mail address matches another Apple ID she forgot she had. I was unable to change the Apple ID via appleid.apple.com, but a warning dialog on that site allowing you to change your Apple ID to match your primary e-mail address seemed not to notice this error, and all was good.

Thinking about Apple IDs, I decided to try and do something about my old @mac.com Apple ID. I registered for Apple’s old “.Mac” service a few months before MobileMe was announced. Apple upgraded all .Mac subscribers to MobileMe, aliasing our e-mail addresses and Apple IDs to work whether we addressed them as something@mac.com or something@me.com. As time wore on, the convenient aliasing grew minutely annoying, and I wanted to force the Apple ID to always display as “@me.com” (various dialogs never do).

I tried using appleid.apple.com to no success, and contacted Apple via their chat support. I was alerted that renaming my Apple ID was not supported, but was told Apple greatly values customer feedback, and directed me to this page, which I encourage anybody concerned about this issue to do.

There have been rumors that Apple may offer this service in the future, and I hope they do so.

iTunes Match was made available with the launch of iTunes 10.5.1. For $24.99 / yr, Apple will store up to 25,000 songs in the cloud (iTunes Store purchases not counted against that number), using a process they claim is faster than their competitors because it can match items in the iTunes Store based on song fingerprints, allowing one to avoid quite a lot of uploading (a complaint I’ve heard with Google Music).

As someone who takes their digital music library quality seriously, I’ve made some notes that might interest others:

• Matching seems pretty good. I haven’t run across any songs that I know are in the iTunes Store that aren’t labeled as “matched”. But there seem to be a few cases where one or two tracks off an album aren’t matched while the rest are. I can confirm these unmatched tracks are in the iTunes Store. It doesn’t seem to happen very often but I’ve yet to detect what’s wrong with the file that causes the match to fail. Additionally, when two albums (both on the iTunes Store) have different versions of a song, I’ve had it match against the wrong version.
• Quality upgrading is not automatic. Switch to List view and add the columns “Bitrate” and “iCloud Status”. If the bitrate is not 256kbps but the iCloud Status is “Matched”, go ahead and delete the file (do not check the box asking you to delete from iCloud as well), and click the re-download button that appears to get the iTunes Store 256kbps AAC version.
• Based on what I’ve read, you can keep the files even if you stop paying for iTunes Match. They’re DRM-free anyway, so you could ensure this is the case by copying the files away.
• Metadata is not changed to match the iTunes Store. There’s also no option to do so (keeping products like TuneUp relevant). If you, for instance, change the genre of a song, delete it, and download a copy from iCloud, it will still have your genre. Perhaps this information is stored not only in the .m4a file but in your iTunes metadata. I’m uncertain how to get iTunes Store-quality tags at this time without manually entering them. I am also uncertain if metadata is changed across multiple devices when one device is manually updated.
• The encoder used is different than what iTunes itself offers. I ripped a CD at 256kbps AAC with iTunes 10.5 (My Bloody Valentine’s “Soon”, off the album Loveless) to produce a 14.1 MB .m4a file. The iTunes Store matched copy is also 256kbps AAC, but is a 14.7 MB .m4a file. 0.6 MB difference seems to large to merely be metadata differences. Another track on this album had an iTunes Store copy that was 0.2 MB smaller than what the iTunes ripper/encoder had produced. The available encoder is updated every now and then with new versions of iTunes, and if I had to guess, Apple probably only encodes files once (when they receive the album from the distributor) and does not go back and re-encode with each new version of the encoder. I don’t know this for sure.
• On iOS betas, I could have sworn there was a “don’t download matched songs on 3G” toggle, but I’ve yet to find this in the final build of iOS 5.0/5.0.1.
• As you cannot delete items from your library in a smart playlist, making one with the criteria “iCloud Status is matched” and “Bitrate is not 256kbps” doesn’t help too much. You can sort columns in the details view and mass delete/download fairly quickly though. Macworld has this guide to using Smart Playlists to quickly upgrade what tracks are eligible.

After dealing with the woes of MS Exchange at work, I decided to take a look at Zarafa, an open groupware “server” (it’s really a collection of separable daemons) similar to Zimbra: open source e-mail, directory, calendar, contacts, etc.

Unlike Zimbra, however, Zarafa supports utilizing existing daemons (MySQL, Apache, OpenLDAP) instead of installing its own (though, IIRC, it can install its own), and it’s CLI administration tools seem a bit stronger. It also seems to offer native MAPI support (the protocol used between Outlook clients and Exchange servers), though I have yet to test this functionality (it’s not available as open source and the free binary version only supports up to three clients).

I’ve already configured Dovecot (IMAP) and ESMTP (SMTP) on a CentOS 5 server (without Zarafa), but I have no decent CalDAV server. Enter Zarafa.

Installing Zarafa on CentOS is fairly easy using yum:

yum install zarafa-server zarafa-caldav

And starting it:

/etc/init.d/zarafa-server start
/etc/init.d/zarafa-ical start

Configuring Zarafa was easy, but not entirely straightforward. Here are some tips:

• It seems to store information in MySQL at localhost. Be sure to edit /etc/zarafa/server.cfg with your MySQL root password.
• If you want to utilize /etc/shadow for user authentication, as I did, edit /etc/zarafa/server.cfg and set it to Unix. You’ll have to also change zarafa-server to run as root, though zarafa-server can then be configured to only listen locally so as to minimize the security implications (zarafa-ical runs as a separate process as the zarafa user).
• OS X Lion’s iCal seems to be broken as of Zarafa 7.0.1. I haven’t tested it under 7.0.2 but the Zarafa folks seem to be aware of the issue. This also affects iOS 5. Thunderbird+Lightning works fine.