I’ve got a plethora of external hard disks attached to my MacBook Pro. One for my personal media files and Time Machine and another two for video editing. At some point the drives go into sleep mode which proves an aggravation in Final Cut Pro because they need to spin up after their slumber.

The Energy Saver preference pane has an option to “Put hard disks to sleep whenever possible” which I unchecked. The drives no longer spin down but this means constant whirring of motors and fans when the MBP is doing nothing.

An ideal solution is using AppleScript to control hard disk sleep mode when using Final Cut. Although I haven’t found an existing script for this I did find two tools to modify the sleep timer.

A tip from MacRumors suggests using the command-line tool pmset to view and change the sleep timer.

MacOSXHints points to the Developer Tools and an application called SpindownHD which sets the timer via the Mac GUI. This works successfully although the “device scan” listing doesn’t show any drives in 10.5 (for me anyway).

Using this tip from MacOSXHints I’d like to create an AppleScript to modify the hard disk sleep timer via pmset or just automating SpindownHD. More on this in a later post.

My user account debacle had another side effect. Opening a project in Final Cut Pro produced error “this project is unreadable or may be too new for this version of Final Cut.”

A mild panic set in since I was running the latest version of Final Cut. Add to that none of my projects from the AutoSave Vault would open due to this error.

After some digging around I discovered what I’ll call a bug in FCP 6.02: absolute path references to files in a project. While absolute paths aren’t unusual it’s the fact they seemingly break your project when those files aren’t accessible. In my case I no longer had access to my old user account home folder but FCP was trying to access those files and couldn’t.

Instead of asking to reconnect the files (as is customary) it simply threw the nasty error. My quick fix was to chmod 770 my old home folder until I had everything moved over and renamed properly.

Apple’s FCP support group has more to add.

For reasons unknown, my Mac’s user account spiraled out of control. A few moments after login the MacBook Pro’s fan kicked in, mouse pointer became erratic then unresponsive, and the spinning beach ball stayed for good. Only way out of this deadlock was a hard reboot.

I only had a few moments to launch Activity Monitor to discover the Spotlight service (mdworker, etc) was pegging the CPU. Unfortunately, nothing related to Spotlight resolved the problem. Here’s what got me working again…

This is a summary of what I did and not meant as a step-by-step solution. You’ll need a decent grasp on the UNIX command line for success.

• Login as root (enable it via Directory Utility from an admin account).
• Open Terminal and create a tarball of the home folder to a destination volume with enough space: tar cvf [dest] [home-folder]; this is critical because you need hidden files not always copied by Finder.
• Create a new user account.
• Delete the contents of that (new) home folder.
• In System Preferences / Accounts, delete the problematic user account; don’t delete the home folder in case you need it later (the old home folder is renamed with the suffix “(Deleted)”).
• Rename your new user account to that of the old one.
• Untar the tarball: tar xvf [tarball] [home-folder].
• Rename the new home folder to that of your old one: mv [new-home] [old-home].
• Edit the new user account and verify it’s pointing to the new home folder.
• Ensure the new user account is the owner and has RW permission to the new home folder; may require chown -R [new-user] [home-folder].

Result? A new, and working, user account with the same configuration and files as the old one. This solution has the benefit of retaining the identical user and home folder name to avoid issues with configuration files.

There are probably variations to this process but this worked for me. I should note this was performed under OS X 10.5.1. Be sure to disable the root account when you’re finished.

I’ve been using a debranded Nokia N75 since I switched from T-Mobile to AT&T Wireless. On numerous occasions I want to hurl this device into the depths of Hell while I laugh fiendishly. Don’t get me wrong … Nokia knows how to make a great device like the N95 but they have some real stinkers like the N75.

My firmware version:

V 10.2.055
24-04-07
RM-128

The list of bugs I encounter on a regular basis:

• Bluetooth connection with headset overwhelmed by static: restart BT or reboot phone
• Image Gallery out of memory viewing an image: reboot phone
• Web browser out of memory: reboot phone
• On one phone call, accept another, drop second call, cannot return to first call: need to terminate the call and start over
• Email auto-check stops working: no idea
• Full bars, call drops: no idea
• Terminate one call and rapidly dial another: won’t make the call
• Searching for a contact: the first character takes an eternity to display on the screen and there is no buffering
• Predictive text has an incorrectly spelled word: no idea how to fix

Rebooting the N75 every few days (or every day) takes care of the memory bugs but the others remain. Many times I have considered getting an N95 but Nokia’s track record of software updates is abysmal. My unbranded E61 was testament to this and now my craptastic N75.

I suppose there’s a reason Apple has grabbed more than 25% of the mobile device market in less than a year.

It was only a matter of time before iCal, .Mac, and Plaxo caused a catastrophe. This afternoon, out of nowhere, my iCal calendars were duplicated three times. Figuring it was Plaxo’s doing I removed those calendars (from Plaxo) and within seconds it nuked everything in iCal. After a quick trip to Time Machine, iCal was restored to working order and I told Plaxo to reset its sync point. This got iCal and Plaxo working again.

After an iSync my Nokia N75 had two copies of each calendar entry. iSync’s Reset Device option didn’t work and I wound up with three duplicate entries. Nowhere could I find a method to delete calendar entries from the N75 so I started poking around Symbian’s Sync feature. It wasn’t long until I realized Apple’s iSync held the answer.

I removed the N75 from iSync and re-added it which presented a pop-up menu for handling a first-time sync. The best selection was Replace All Data on Device and with fingers crossed I clicked on Sync Devices. A few minutes later the N75’s calendar was back to normal.

In short, try iSync’s Remove Device instead of Reset Device when attempting to delete badly synchronized data from your mobile.