njr 3.0

These days nearly 100% of my iPod listening is podcasts, and iTunes’ iPod-syncing podcast support is decent but lacking in a few areas.

One issue that bugs me is that, after connecting my iPod, I must update podcasts then update the iPod again in order for the already-listened episodes to disappear from the iPod. While the play counts update on the first, automatic iPod sync, the associated action (removing the corresponding episodes) doesn’t happen until you do another podcast update.

Another issue is the update timeout—after a few days if you haven’t played an episode of a podcast, it’ll stop updating. For people like my father who abandon their iPod for months at a time (hi, Dad!) it is a great bandwidth-conserving idea, but for me, with video podcasts and a non-video iPod, I like to accumulate episodes to watch when I’m exercising at home.

One of Doug’s AppleScripts for iTunes handily solves the second issue, and I’ve written a script to deal with the first. iTunes doesn’t let you query its iPod update status, so I instead wait for iTunes to unmount the iPod. I found this script which periodically checks the iPod disk space usage, but it fails for me, probably because iSync takes a long time to often do nothing.

Embedding this bash script into AppleScript was a real pain, what with do shell script‘s many and varied limitations, as I had to remove line breaks, indentation, my use of extended globs and even the while loop, because iTunes failed to finish updating the iPod while the script was executing. I think I will be checking out the newly revived PyOSA so I can do all this in Python instead.

Download the AppleScript, unzip it and place it in ~/Library/iTunes/Scripts.

(Note: this script is only tested on my Mac with my 3G FireWire-connected iPod; it definitely won’t work if you have iPod disk mode turned on, and may not work on other configurations.)

8:37 PM | Computing, macOS
2 Comments

This is the first new year I can remember that I haven’t spent with family or friends; instead, I had a quiet night at home cooking Indian food and flailing at leftover crossword puzzles.

2007 is a year a lot of things will be changing for me, and I hereby resolve to try my hardest to make sure the transition is a smooth one.

Happy new year, everyone; may this year be better than last.

7:01 AM | Administrivia
No Comments

So Illinois is mandating carbon monoxide detector/alarms in residences as of January 1. Today I decided to buy one. I wanted to get a combination smoke/CO detector, that way I wouldn’t need to change two batteries. Sounds easy, doesn’t it?

Let’s see, this one is on clearance because its battery lasts 2 weeks.

This one seems to give a lot of false alarms, and has a rather humorous review attached.

Reviewer: A Kitchen & Housewares enthusiast
This is not and I repeat is not a good alarm. There is one alarm light and you can hardly tell which one is sounding. It looks as if the specs are lying to me and I hate lies. Also the battery died after 6-8 months. The low battery alert is loud and chirps so anoyingly. I also noticed that the alarm sounds a loud shrieking alarm when it sounds. I will return this alarm. Never again will I trust in First Alert!

It also makes me wish I never meet a “kitchen and housewares enthusiast” in person.

This one goes off when you try to use an infrared remote control. The detector goes in the hallway behind my stereo, so that one’s out.

Finally, I give up on Amazon.com and do a Google search. I eventually stumble upon the Firex 12000, which has such useful features as a mute button that actually mutes for longer than you hold it down, an alarm that starts out quiet, a battery that’s easy to replace, and an industrial design that looks vaguely like someone cared. It’s AC/DC so I don’t have to replace batteries every 6 months, and even communicates over the power line with other units of its type. I read prior ones have freaked out after 4–6 years, but I plan to be gone by then.

A bonus review (for a CO-only alarm). The username is a nice touch.

4:43 PM | Web
3 Comments

The biggest day-to-day annoyances I’ve had since 10.0 have been, in descending order of irritation:

• Fonts: inconsistencies between rendering paths, bad support for bitmaps (I still can’t use my favorite font in BBEdit), ATSServer hangs/crashes, silent refusal to activate, font cache corruption, worthless Font Book interface, etc.
• Disks/filesystems: HFS+ slowness, Spotlight flakiness. AFP instability, slowness and complete inability to handle concurrent accesses. Disk Arbitration flakiness. Disk imaging instability and yet more flakiness. Flaky network browsing. Still no LVM. ZFS on OS X can’t come too soon—it’s been a joy to use on Solaris.
• USB: crashy drivers (less so of late), poor transfer throughput, overly aggressive port deactivation and poor feedback when something appears to go wrong. Some of these problems might be hardware—this Intel mini doesn’t work with my external USB 2 enclosure, whereas my iBook worked fine.
• Finder (need I say more?)

Today alone I spent about an hour troubleshooting font problems. First I spent about four reboots trying, and eventually failing, to get the fonts in ~/Library/Fonts to activate. No amount of font cache trashing or safe booting fixed it; I eventually just renamed the folder and told FontExplorer X to import them, at which point everything worked… until half an hour later when Camino hung then Terminal hung (as did every other app I tried, such as Dock and LaunchBar). Turned out ATSServer was using 100% CPU in some C++ destructor. I had to SSH in from another machine to kill ATSServer, at which point everything started working again. Guess I should be glad that it worked, or something.

I wonder how bad the underlying code really is, and pray it’ll get some attention in Leopard.

7:28 PM | Computing, macOS
6 Comments

launch 1.1 is out. I started working on it back in March, but after rewriting most of the launching logic only to find out that the feature I was implementing (command-line arguments) didn’t work because of an Apple bug, I got a bit disheartened. Finally, some email prodding from Peter Hosey, the Intel mini I got last week at school (thanks to my advisor), and good old-fashioned burnout after getting back from Portland caused me to finish it up.

Changes in this version:

• -L: send “launch” (ascr/noop) event to app, bypasses automatic opening of untitled document, etc.
• -o: pass command-line arguments (still broken)
• display content type ID (UTI)
• display architecture of Mach-O files
• switched to new LSOpen APIs (now requires Mac OS X 10.4 or later)
• switched to new date formatting APIs (the old ones are deprecated)
• for compatibility with open, take app path as argument to -a
• Universal Binary, compatible with Intel Macs

Sample output demonstrating some of the new features:

% launch -f /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib: document
        type: ''        creator: ''
        architecture: PowerPC, PowerPC 64-bit, Intel 80x86, Intel x86-64
        kind: Unix Executable File
        content type ID: com.apple.mach-o-dylib
        data fork size: 7.62 MB on disk (7983880 bytes used)
        created: 9/29/06 6:50:49 PM
        modified: 9/29/06 6:50:49 PM
        accessed: 10/30/06 5:19:11 AM [only updated by Mac OS X]
        backed up: 12/31/03 7:00:00 PM

Now to crawl back into my hole and attempt to finish this paper…

5:22 AM | Computing, macOS
No Comments