When to Buy A Big Video Server Hard Drive

On February 9^th of this year, a Seagate Barracuda 750GB internal hard drive cost $300 shipped according to DealMac. By May 18^th, that number had dropped to $200. (A 500GB drive dropped from $144 to $110 over the same period, while a 250GB drive kept at a constant $60.)



So, the price of a 750GB drive dropped by about $33 a month over that span. If I had purchased a drive back in February, I'd now be wondering if I had gotten $100 worth of convenience out of it. I'm guessing not. On the other hand, it would seem silly to await the end stages of obsolescence the 250GB drives now occupy, my son is steadily making coasters, after all. With 1TB drives now available, there should be even more downward pressure on the 750GB, perhaps in a month or so it will be down to $170 and the depreciation will approach a more manageable $15 per month; or maybe it will accelerate, nobody knows, we can only guess.

Why don't I buy two 500GB drives, and get an even bang for the buck ($.22/GB versus $.27/GB)? Four reasons:

• I'd have to put those drives in either 1 expensive case or 2 cheap cases, ruining the price advantage.
• If I put them in one case, it would presumably be in a RAID-0 configuration with an increase in probability of catastrophic loss. If I put them in 2 cases, it'd make their use just that more complicated.
• I'd have to provide power for the extra hardware, and at a couple dollars/month extra over the lifetime of the drive, it adds up.
• More drives equal more heat and fan noise.

Therefore, I'd like to keep with one big drive in a Firewire case—simple, comparatively safe, and fairly energy efficient. I can backup everything I foresee needing on 750GB, and I'm going to say my trigger point is $175. I can attach it to the MythTV in the basement making it available to every computer in the house. Beyond the foreseeable, I'm sure there will be inexpensive 1.5TB drives in a couple years and I can do an upgrade then.

[UPDATE: a 500 GB drive dropped to $100 shipped over the weekend. I'm now thinking that by adding an internal SATA port on a PCI card, I could install such a drive inside my Linux desktop, avoiding the need for an external enclosure, and yet another "box with green LEDs" on my desk. I paid for the SATA power connector on my power supply, and it's about time I used it. This would be $100 cheaper, and I can supplement the storage space with unused bytes from the other two hard drives in the computer. The Windows partition, in particular, has a lot of free space.]

[UPDATE 2: I could not deny the sweet spot of the buying curve, so I bought a 500 GB Maxtor Ultra16 SATA drive ($100) along with a Rosewill PCI to SATA adaptor ($19). I installed it in an open drive bay in the basement MythTV box, where the combined card/drive combination added 12W to my energy usage when in use and 2W when in low power mode. The drive formatted to 459 GB (480,719,056 KB) using the ext3 file system standard to Linux, so plan accordingly.

It was a mistake to get that particular SATA card, as it only has one internal connector. I'll have to replace it when I max out my drive bays. On the other hand, it popped in and worked under Linux with absolutely no extra effort.

There is one open drive bay left, and in a few months I can buy another 500 GB at a reduced price, finishing off my storage needs, and making my basement uninhabitable with all the noise. In the meantime, I can drive DVDPedia with my Wiimote, and have my favorite content available in a few clicks. Now, if only I could afford a Mac Mini...]

Porting Model Railroading Software to OS X From Windows

Last week, TrainPlayer International released a Mac OS X version of Train Player, their application for designing model railroads. I had something to do with this. I setup the general structure of the application at the start of the porting project, implemented a number of features, and worked into the debugging stage. But my real job has been nothing but debugging for the last two months, and I have nothing left to give to side projects, so they've had to get along without me.

This blog entry is the first of two on the project. This will cover GUI differences between a Windows application and a Mac OS X application, in terms of user expectations. The second will be on designing an application under the hood to share code between a Cocoa application and an old MFC application.

What Mac Users Want

The first thing I noticed about the interface was the surfeit of toolbars. With buttons for nearly every action.

When I worked in Illinois, we called this "Marketing Mode." Compare this with the left

and the right side of Apple's Pages word processor.

Apple Pittsburgh spent untold hours categorizing the actions required to lay out text, and distilled them into six icons. I can imagine the pressure they felt to add a special button here or there for someone's pet function. "What about a spell check button?" But it is important that toolbar icons be few and large in order that mouse acquisition times be short, requiring thoughtful selection of buttons. Notice there is plenty of room under the large icons for actual descriptive words; sometimes a word is worth a thousand pictures.

The second thing I noted was how often the user was required to open a modal dialog box, sometimes two, or even three nested modal dialogs to configure some user interface element. For example, to change the labels for a series of railway cars you would select a car, choose "Properties..." from the "Train" menu, to bring up this modal dialog:

which you would modify, hit "OK" and repeat for every car in the series. Modal dialogs are great for programmers; work flow is linear and controlled. If the user hits "Cancel" you just don't change your data structures, while if they hit "OK" nobody expects you to allow them to undo it; you've already given them a chance to back out. It's just so easy. But, Mac users these days are used to more.

The more they expect is a modeless, floating inspector window.

This allows the user to select, change and rapidly select and change again, all without losing focus on the document. It should allow for undoing changes (although apparently that functionality hasn't been added yet to Train Player, but should). The user should feel more comfortable and able to work in a more free flowing manner.

The Windows version used GDI graphics for its rendering needs, resulting in pixelated track paths like this:

I felt OS X's Quartz graphics environment would create much cleaner lines if we treated tracks as continuous paths instead of discrete segments and the Windows programmer was willing to make the changes needed to get nice anti-aliased and beautifully joined paths like these:

Similar effects could be achieved under Windows with GDI+, but I felt the typical Mac user would immediately see what was missing and demand higher quality. Quartz also allows any object to cast a shadow, making this effect: extremely easy to produce. Simple as it is, this translucent shadow makes the cars pop out and resulting in a more realistic look.

Along the same vein, Windows users see this clock:

while Mac users will see this clock with a composited reflective crystal and hands throwing shadows:


The Windows version had a modal dialog to choose individual cars from collections. It had two modes: an icon view and a table view, with each collection selectable via a tab.

I felt there was no need for two modes as the Mac table class was capable of displaying the larger image; and I am leery of using tabs to represent categories, especially when the user could install or create their own. Therefore, I replaced the tabs with a single column table as you might see in an iLife application, and I merged the two modes into a single table grid.


In other areas, I left it up to the experts at TrainPlayer, they know model railroading, whereas I only know generic applications. So when they say this is how you build up a set of tracks, this is how you build a set of tracks:

And this is how you run a simulation on a completed railroad:

I wish YouTube didn't add an ugly filter to its videos. You have to see how pretty it is.

What Was Achieved

In many ways, I'm proud of the result so far, and I expect the application to go through a rapid process of refinement now that it is available to a wider Mac user audience. Areas of the GUI where I varied it from the Windows original are definite improvements, some of which could be back ported to give the Windows user base a taste of Mac refinement.

In other places, I'm not thrilled. After I left the project, too many buttons crept into the GUI, and text fields really should support undo. Today's standards are high, it's hard to keep up, especially while reusing large chunks of C++ code, and bitmap images from a Windows application. The good thing is there is always version 1.0.1.

Porting is a balancing act. You've got to know what code and what GUI elements can be reused, and which must be re-implemented in order to avoid the dreaded "Looks like a Windows port" review. I think we've avoided that, and that's an accomplishment in itself.

Wii Remote + MythFrontend + Remote Buddy + OS X

In most aspects of my life, I have decent impulse control. But when I discovered IOSpirit's Remote Buddy software allowed me to use a Wii Remote Controller to control my Mac, I just had to have one. One-click buying on Amazon, right now, need to have!


I don't even own a Wii; I've never even seen a Wii; I don't know how to pronounce Wii.


I downloaded Remote Buddy, and in 30 seconds determined it was worth 10 Euros. I am impressed by the degree of finish this little product shows. As an application developer I can tell when somebody put their love and creative soul into a product, and Remote Buddy shows this. And IOSpirit is actively improving Remote Buddy too, just last night they released an update which made a marked improvement in the interface and, apparently, in the reliability of button pushing.


When the Wii Remote Controller arrived from Amazon, the longest step in the setup was inserting the batteries. Remote Buddy paired quickly with the remote and I was soon driving my Mac from across the room.


IOSpirit has full support for all the buttons on the remote except the power button, which I guess must control an infrared emitter instead of using Bluetooth, nor does it have any apparent tie into the accelerometer's inside the remote, or the speaker [Update: After looking over the support forums at IOSpirit, there is support for virtual mousing with the accelerometer, but it involves providing a strong infrared beacon (a candle) to give the infrared sensor on the remote an extra frame of reference, and is therefore probably not very practical] [Update 2: I built a 3 Infrared LED based emitter using the circuit generated by this online calculator This is a lot more convenient than mousing via cursor keys, but is a bit wobbly especially when double clicking]. The way it controls Front Row and iTunes is extremely slick, with lots of use of the Heads Up Display (HUD) windows which are so popular these days.


There was no pre-set for the MythFrontend application, so I ran the "Behavior Construction Kit" to create an identity for MythFrontend, and then went to the Behaviors preference to configure the buttons. Note that some buttons can have separate actions assigned to when you briefly press the button, and also when you press and hold the button. For other buttons, Remote Buddy requires you to press and hold the button, presumably to avoid inadvertent presses with one's palm.

Button	Action
Up	Cursor key up
Down	Cursor key down
Left	Cursor key left
Right	Cursor key right
A / Play/Pause	"P"
A / Play/Pause (held)	Spacebar
B / Menu	Escape
B / Menu (held)	Open Remote Buddy menu
Home	Escape

The trigger shaped "B" key on the facing side of the remote was the most complex to figure out. In normal practice, its used by Remote Buddy to bring up its HUD menu, but I liked its behavior in Front Row where clicking the "B" key goes one menu layer up, while clicking the round "A" key digs one menu layer down. Also in Front Row, clicking and holding the "B" key brings up the Remote Buddy HUD, and this seems a good compromise.


For simple watching of TV and recorded programs, you can drive MythFrontend with 7 buttons, which is a little unfortunate because the Wii has 6 buttons in comfortable reach of the thumb and forefinger. The space key which is used to press some buttons, such as the quit confirmation, and to bookmark show positions is infrequently enough used that I assigned it to holding down the "+" button. I also assigned space to the hold state of the "A" button, but time will tell if I get into the habit of using it. [Update: Time has told, and I use the held down A button.] I could assign the other buttons ("-", "home", "1", "2") to handle less frequent commands, such as zooming, or bringing up the program guide, but I've never gotten into the habit of using those MythTV features. For me 7 buttons are sufficient. I do wish MythTV allowed the right cursor button to push any selected onscreen button. The few that act differently stick out and annoy.


For pure driving of the interface, the Wii remote is excellent. The remote has a heft I miss with the Apple remote, and fits comfortably in either hand with the forefinger and thumb resting next to their buttons ready to spring into action, rescuing me from commercials. Being wireless, there is no need to point, and button pushes are reliable, with little need to look at the remote during use. I haven't felt the need to use the attached strap, my TV watching is not quite that kinetic.



Remote Buddy's menu system makes it easy to switch between media applications or control iTunes in the background while having a more reliable Bluetooth remote makes driving Front Row more pleasurable.

The downside of the remote is it's being radio frequency based, and thus can't be used to drive my TV or stereo receiver. I still need my Harmony 550 to control those, and since I can use the 550 to drive my MacBook anyway, by pretending to be an Apple remote, the question then becomes is it worthwhile to have a separate Wii remote just to control the MacBook. That's a tough question. Certainly the integrated solution is simpler and cheaper, on the other hand, the Harmony is a complicated, general purpose remote and is not optimal for driving a 12 foot interface. You spend a lot of time staring at the Harmony, finding the button you've mapped to mimic the Apple Remote's "Menu" button, and the cursor buttons have nowhere near the smooth action of the Wii remote.


When the Wii loses touch with the Mac (sleep, leaving its range, baby takes the batteries out), you will have to re-pair it, which can quickly be done by pressing the 1 and 2 keys simultaneously. Remote Buddy will re-detect it within seconds.


In summary, using a Wii remote to drive the MythFrontend, and other multimedia applications is fun and convenient. I'm looking forward to the day when I can put a Mac Mini in my TV room and get down to doing some serious viewing.
[Update: I notice that Remote Buddy will go into a mode where it uses a lot of CPU cycles (10% of a core) waiting to pair with a missing Wii remote. I'm assuming this is something IOSpirit can fix.]
[Edited for grammar, and inserted photo since first published.]

[UPDATE: I spent a happy weekend with my MacBook hooked up to the HDTV in the TV room. I mounted a SMB share from the Linux box in the basement with a bunch of video content selected from DVDPedia, drive the Apple DVD Player, as well as watching TV via the Myth Frontend, listening to iTunes, watching movie trailers in Front Row. I even lazily browsed the Internet using the remote as a mouse. It was fun--and yes, I should get out more. The only problem with the remote itself was Myth Frontend would not get the pause command the first time so I will end up clicking it 3 times to pause.

The RemoteBuddy DVDPedia setup did not include the command key for launching linked files (Command-L), so I mapped it to the home button on the Wiimote. Annoyingly, the DVD Player had to be quit before moving to a different movie, as the DVD Player / DVDPedia interaction would go into some sort of loop preventing playback.]

Streaming video to VLC from MythWeb

After building and installing the latest MythTV version, I browsed through the mini-website, MythWeb, which gets installed and served by Apache. There is a page for all my previously recorded programming which comes up as a table:



It's a nice refinement from previous versions, but what caught my eye was this newly added icon:



Mousing over it gives a tooltip: "ASX Stream" and clicking on it causes a file to be downloaded with the double extension ".asx.asf". What is that? By default, on OS X, Quicktime was set to open .asf files, but Quicktime didn't know what to do with it. So, I reassigned the file type to the VLC player. Now opening the file (which you can do by right clicking on Safari's download window) launches VLC and starts playing the recorded program. No more relying on the, somewhat clunky, MythTV frontend for displaying recorded content. Instead, you can use the much more refined, and Mac-like VLC player in either windowed or full screen mode.

This is not perfect. VLC can't fast forward, jump forward, or scrub through the stream. So the MythTV frontend is still more functional, unless you want to watch commercials. OS X gives 5 applications which are registered to handle the .asf file type: VLC, MPlayer OSX, MPEG StreamClip, Windows Media Player, and WMV Player. Only VLC can actually use the file as generated by MythWeb.

I don't know what is missing from the stream (or VLC) but I wish somebody would add arbitrary scrubbing. It would be very cool to use VLC for my TV viewing. And it'd also be nice if MythWeb added a TV tuning page, and live TV streaming. And it would be even nicer if it the tuning page handed off my HDHomeRun's network stream directly to VLC instead of acting as a proxy.

Still, a really cool feature.

[Update: I couldn't actually watch a whole program without losing the stream, but it'd be cool if it worked.]

DVD Main Title Size: Where the Gigabytes Go

For my personal edification, I've been surveying my DVD collection in terms of how much each movie uses on disk. This is the main feature only, none of the extra fluff, but it does include wasted space taken up by language tracks which I do not speak. This is movies only, not TV shows.


So far I've found 187 movie DVDs around the house. There are discs my son has reduced to coaster status, and I've no idea where ⅔^rds of the Indiana Jones trilogy ended up. I feel that is enough to get some feel for what the average movie uses on disk and how it correlates, if at all, with quality.


So some stats:

• Disks: 187 disks
• Average size of Main Feature: 5.10GB
• Largest Main Feature: 12.94GB over 2 Disks: The Return of the King
• Largest Main Feature on a Single Disk: 7.60GB King Kong
• Smallest Main Feature: 3.08GB Sleepless in Seattle (which had plenty of room for both Thai and Korean subtitles)
• Total GB: 948

Some surprises:

I have the Superbit version of Panic Room, the cheapest Superbit title I could find. Sony claims that Superbit is great because they fill up the whole disk with movie, making it as uncompressed as possible while allowing for both a Dolby Digital and a DTS soundtrack. Well, Panic Room clocks in at a measly 5.66 GB, leaving nearly 2 GB of room which could have been used for less compression. Having said that, the picture quality is quite good as it is. My other Superbit title, Adaptation, leaves around half a gig of empty space on the disk. Is it false advertising if you claim the highest quality DVD, and it turns out you could have made it even better by using less compression?

And how did Pirates of the Caribbean end up with only 3.61 GB? It was a special effects blockbuster with a huge marketing budget. They couldn't spend some tweak time getting a better picture?

Breakfast At Tiffanies is just the opposite, despite being quite pedestrian in its appearance, having only mono sound, and being none too long at 115 minutes manages to use up 7.18 GB. Where does it all go?



The disks that have the most movie on them tend to be major blockbusters: The Lord of the Rings, Minority Report, etc. where a lot of tweaking time can be spent getting everything to fit, or are just plain long (Patton). Disks with the lowest space usage tend to be catalog romantic comedies originally released pre-DVD. The studios didn't spend much time getting the highest quality disk, perhaps in the hope of coming back in a few years with a "Widescreen Collector's Edition", such as was the case with The Big Lebowski (3.54 GB), L.A. Story (3.57 GB), and Sleepless in Seattle (3.08 GB). By way of comparison, a short exercise DVD "Post Natal Yoga" clocks in at 3.94 GB.

[UPDATE: Here's a histogram of number of disks per size. The cut off for a single-sided, single layer disk, 4.7 GB minus a few trailers, is pretty obvious. I'm a bit surprised by the shape of the curve; if I had had to guess beforehand, I would have thought that there would have been two peaks, one just below the maximum capacity of a single layer, and another just below the maximum for a dual layer. But once you get passed the minimum for a single layer, it's almost as if it's following a random uniform distribution.]
[UPDATE: Updated for more disks surveyed.]

Logitech Tech Support Driving Me Up the Wall

I had written this entry weeks ago, meaning to do some more research before posting it, and I had forgotten it with my busy work schedule, but this blog entry: ill-Logitech seemed so similar to my experience I thought I should post this.

Before I begin this in earnest, I like Logitech products. I have owned many of their products: speakers, Harmony remotes, game pads, and cameras. They make the kind of gadgets I love to own. I am also not angry with Logitech or their tech support person who was courteous if pointedly unhelpful. This is just a story of spinning one's wheels in the pursuit of technological promise. I am also not including the text of actual exchanges with the tech support person at her request; you will have to rely on my characterizations of what happened. If anybody at Logitech is interested, this is Incident: 061224-000580

Now in earnest. I came across a cool racing simulator for the Mac, Redline by long time Mac gaming house Ambrosia. I had a good time playing it from the keyboard of my MacBook (1.83 GHZ Dual Core, 2GB RAM), and had some idea that if I added a steering wheel I could enhance my fun, and maybe give my wife, who's learning to drive, some simulated road time.

I went Googling and found that Logitech's MOMO racing wheel was well regarded and people had used it to play Redline on their Macs. I took a deep breath (maybe not literally) and ordered one from Amazon. It came, and like a kid at Christmas, I scrambled to unpack it from it's hefty box, mount it firmly on my desk, plug it all in and fire up Redline. Open up Options, Analog Controls, and what do I see but that the Force Feedback controls were disabled. Oh, it could see the wheel. I could calibrate the steering and braking, assign the horn beeping to one of the buttons on the wheel, etc, but I was denied the joys of having my steering wheel lose resistance when spinning out on ice, or stuttering in my hands when I slammed into a canyon wall at 120 MPH.

First things first, replug, restart, reboot, always greyed out.

I did notice that the motors in the wheel were working as whenever I plugged it into a USB port, the wheel would spin itself back to center.

Then I went to the Redline support forum, and found other people with the exact same problem, and others for whom the wheel worked as advertised.

And by advertised, I refer you to Logitech's Product Page which gives the following requirements:

• PC with 166 MHz or faster Intel Pentium® or compatible AMD® processor
• 64 MB RAM
• 20 MB available hard disk space
• CD-ROM drive
• USB port
• Windows® 98, 2000, Me, or XP
• Mac® OS X 10.2.3 or later*

* Requires game that supports force feedback. Check with developer

Needless to say my MacBook exceeds these specifications in every way, excepting the PC part or the Windows part. And the developer certainly says Redline supports force feedback.

I posted onto the forum and exchanged some information with the Ambrosia people, but they didn't know what was happening, and the copy of the wheel they had in house was working fine. I began to wonder if it was a bad batch of wheels or an incompatible firmware.

I sent Ambrosia the USB Prober trace for the wheel:


Low Speed device @ 3 (0x1D100000): ............................................. Composite device: "Logitech MOMO Racing "
Device Descriptor
Descriptor Version Number: 0x0110
Device Class: 0 (Composite)
Device Subclass: 0
Device Protocol: 0
Device MaxPacketSize: 8
Device VendorID/ProductID: 0x046D/0xCA03 (Logitech Inc.)
Device Version Number: 0x0019
Number of Configurations: 1
Manufacturer String: 4 "Logitech "
Product String: 24 "Logitech MOMO Racing "
Serial Number String: 0 (none)
Configuration Descriptor
Length (and contents): 41
*** omitted raw descriptor ****
Number of Interfaces: 1
Configuration Value: 1
Attributes: 0x80 (bus-powered)
MaxPower: 80 ma
Interface #0 - HID
Alternate Setting 0
Number of Endpoints 2
Interface Class: 3 (HID)
Interface Subclass; 0
Interface Protocol: 0
HID Descriptor
Descriptor Version Number: 0x0100
Country Code: 33
Descriptor Count: 1
Descriptor 1
Type: 0x22 (Report Descriptor)
Length (and contents): 87
*** omitted raw descriptor ****
Parsed Report Descriptor:
Usage Page (Generic Desktop)
Usage (Joystick)
Collection (Application)
Collection (Logical)
Report Count............ (1)
Report Size............. (10)
Logical Minimum......... (0)
Logical Maximum......... (1023)
Physical Minimum........ (0)
Physical Maximum........ (1023)
Usage (X)
Input................... (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield)
Report Count............ (10)
Report Size............. (1)
Logical Maximum......... (1)
Physical Maximum........ (1)
Usage Page (Button)
Usage Minimum........... (1)
Usage Maximum........... (10)
Input................... (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield)
Usage Page (65280)
Usage 0 (0x0)
Report Count............ (4)
Input................... (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield)
Report Count............ (1)
Report Size............. (8)
Logical Maximum......... (255)
Physical Maximum........ (255)
Usage Page (Generic Desktop)
Usage (Y)
Input................... (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield)
Report Count............ (3)
Usage Page (65280)
Usage 1 (0x1)
Input................... (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield)
End Collection
Collection (Logical)
Usage 2 (0x2)
Report Count............ (7)
Output.................. (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Nonvolatile, Bitfield)
End Collection
End Collection
Endpoint 0x81 - Interrupt Input
Address: 0x81 (IN)
Attributes: 0x03 (Interrupt no synchronization data endpoint)
Max Packet Size: 8
Polling Interval: 10 ms
Endpoint 0x01 - Interrupt Output
Address: 0x01 (OUT)
Attributes: 0x03 (Interrupt no synchronization data endpoint)
Max Packet Size: 8
Polling Interval: 10 ms


I would think the data in this probe log would be useful to tracking down where the device was failling to be recognized. For example, the USB standard for Physical Input Devices indicates to me there should be another "PID" interface which could be used through a driver to cause a force feedback action.

Regardless, I thought it best to not bother Ambrosia too much; they are a small house and might not have the resources to track down such an obscure problem.

I e-mailed tech support at Logitech and shortly got a response asking me to perform a variety of actions, most of which were reasonable, of the "is it plugged in?" variety, but one really stuck in my craw and seemed to be an open invitation to give up bothering Logitech and go away. The tech support asked me to test the wheel with a PC game! And if I didn't, no tech support for me.

First of all, it's a near fluke that I own a PC. It will give you a hint to know my PC's network name is SCORNED. Second of all, they didn't say "Download this tester app from our website." They didn't even say, "Here's a list of games which we know work. Try a demo." No, they told me to find an unspecified game to test it on what could well have been my non-existent PC. Or no tech support for me.

Well, I mulled on that for a week or two. Meanwhile, I got an e-mail saying that if they didn't hear from me within 120 hours they would assume I was happy and close the incident.

I won an Amazon gift certificate in a drawing at work, so I looked around and found a popular game for the PC, GTR2, which was known to work with the Logitech MOMO, and I bought a $20 copy.

Of course, the MOMO wheel worked on the PC. I wasn't very impressed by how hard the force feedback was, but it was definitely moving, and the green force feedback lamp on the wheel was lit. In passing, I prefer Redline to GTR2. Realism is good and all that, but it's a lot more fun bouncing off of canyon walls than sliding around some ugly Formula 1 track.

I e-mailed Logitech support, confident that they would now be interested in "The Mystery of The Wheel That Didn't Work on a Mac." Not very much. They asked me to uninstall and reinstall Redline. I know uninstalling is second nature to PC people, but what exactly does that mean on a Mac? I trashed my preferences and overwrote the Redline application with a clean copy. Still no force feedback.

I e-mailed Logitech support with this datum, and was told it was obviously an application specific problem and I should go bother Ambrosia. I downloaded a cute little game called Jammin' Racer which has a picture of the Logitech Momo in their instructions. None of the promised rumbling. The lack of force feedback was not application specific.

I e-mailed Logitech to let them know I had disproved the application specific theory, and offered to do whatever USB Probing they would need to trace down the problem. I also asked if I could blog about this experience. The support tech said they preferred not, and (I'm paraphrasing) I should get lost. Actually, she said I should go bother Mac support. (Who is that? Apple support?) She did mention there was only 1 version of the firmware, so that shot down my working theory that some people had one firmware and force feedback, while others had a different firmware and none.

Warning, Mac programmger voodoo ahead. There is a ForceFeedback framework amongst the system frameworks, and I modified Apple's USB Notification Tool example to find the MOMO wheel and try to extract information about it. Surprisingly, the "FFIsForceFeedback" routine returned true, but the "FFCreateDevice" routine returned FFERR_NOINTERFACE, which I take it means the MOMO does not match the profile of a USB force feedback device. This is probably where Redline and Jammin' Racer fail.

I cannot say who is at fault for the wheel not working properly. The ForceFeedback framework is not well documented, and is probably not a priority at Apple. It's possible there is a hardware incompatibility between the USB ports on my MacBook and the MOMO. It's possible the MOMO is not properly following the PID specification. It's a complicated system with many failure points; I just know I paid for a force feedback wheel and didn't get one.

[UPDATE:] Reader Jonas writes to point out that perhaps the problem is with the LogitechForceFeedback.kext extension
/System/Library/Extensions/LogitechForceFeedback.kext/
which (apparently) comes pre-installed with OS X. His research indicates it is PowerPC only.
[Update 2:] Jonas gets back to me and tells me the kext included with Mac OS X 10.5 developer releases works to bring force feedback support to Intel based Macs according to the forums.

It's Time for Carbon Apps to Support RTF on the Clipboard

I don't know when the 'styl' resource was defined, but I do know it is very, very old. For those not in the know, back in the days of the Mac II, if you wanted to copy and paste bold/italic/underlined/colored/text from your application to another, you put both a 'TEXT' Handle on the clipboard, and a Handle filled with individual style records (the 'styl' flavor), with each record corresponding to a range of the raw text in the 'TEXT' resource. You could even put in foreign words and phrases by switching to lets say a Japanese font. This was what was done in 1987, it was what was done in 1997, and it is what most Carbon apps still do in 2007. I fired up iTunes Friday, copied something from a dialog, and looked at what was on the clipboard: a 'TEXT' resource and a 'styl' resource.

Well, what's wrong with it?

Here is an individual style record from TextEdit.h:
struct ScrpSTElement {
long scrpStartChar;
short scrpHeight;
short scrpAscent;
short scrpFont;
StyleField scrpFace;
short scrpSize;
RGBColor scrpColor;
};
And here are the things you can put in a StyleField:
normal = 0,
bold = 1,
italic = 2,
underline = 4,
outline = 8,
shadow = 0x10,
condense = 0x20,
extend = 0x40
What's wrong?

• No superscript or subscript, not even one level. Try pasting data from a scientific app to MS Word. H⁺₂SO₄^-2 becomes H+2SO4-2.
• It takes an old fashioned QuickDraw font ID, not an ATSUI ID, so it may be difficult to map to the fonts you're actually using.
• No paragraph alignment information. You can have any justification you want as long as it's left.
• Text encoding is by necessity implied by the QuickDraw font encoding.
• The OS has to go through and endian swap every element before pasting across Rosetta.

So what is the alternative?

There is nothing preventing you from supporting the 'RTF ' (Rich Text Format) flavor on the clipboard. It's a Microsoft invention, so you know Word will like it, and it satisfies all the problems I enumerated above. Plus, it's the favored flavor of any Cocoa application, so your text should be more accurately transferred to newer applications.

It's just a matter of implementing it. As I was already mixing in Cocoa into my Carbon application, I built up an NSAttributedString, extracted the string's content using the RTFFromRange:documentAttributes message and stored that raw data in a Handle. When I, inversely, wanted to paste, I extracted styled text information from an NSAttributedString created from the data in an RTF Handle. I did it all in a day for my application. (Sorry, can't share the code.) This has the added advantage of using the exact RTF flavor Cocoa applications get for free.

Alternatively, you could pretty easily create simple RTF documents from scratch using the description of the format in O'Reilly's RTF Pocket Guide. Parsing such documents looks to be a lot harder, but doable, just ignore the tags you aren't interested in.

I could hardly be happier with the result. My users will be getting a nice little present come the next release, and I'm one step closer to expunging the last bit of QuickDraw from my application. If you are maintaining a Carbon application which has anything but the simplest text formatting requirements, do your users a favor and look into supporting the 'RTF ' clipboard flavor.
[Entry has been edited for content since first publication]

The Freedom of EV-DO

My dad is an interesting, and smart guy. He left retail banking 20 years ago to start a software company in his basement, then transitioned into brokering the sale of small planes. And for much of that 20 years, he's sat in that basement, making sales call after sales call. I can't estimate how many thousands of times he's told a prospect to check "w w w dot global dash air dot com." As his phone, his computer and his dial-up Internet connection were in that basement, and he couldn't afford to be away from them, the basement became a prison of sorts.


And then a piece of technology came along to change this. He bought a Dell laptop (a Dell Inspiron E1405), and more importantly, he signed up for Sprint wireless broadband and bought a Sprint Mobile Broadband USB Modem. Suddenly, when combined with a healthy number of cell phone minutes, his business was located not in his basement, but wherever he happened to be. He could visit his friends in West Virginia and Florida. He could spend a week in my basement. He could even hang out with my mom while she was watching grandbabies all over the greater Twin Cities area. Technology has set him free.


And the EVDO modem is faster, even in Dad's rural basement, than his soon-to-be-cancelled dialup. He could stop waiting for the phone company to bring DSL one more mile out of town.


This is the sort of thing technology should be doing all the time. As an engineer, I am always on the lookout for ways to improve the lives of my users. The EVDO engineers at Sprint and elsewhere have markedly improved the lives of my Dad and others like him. It's why a lot of us got into engineering in the first place. Congratulations and thanks to them.

Netscape Plugin Development in XCode

A desperate Google searcher emailed me today asking about getting together an XCode project for a Netscape style plugin. Since this, apparently, is not well known, there is a NetscapeMoviePlugin project in the standard set of examples installed with your developer tools.


/Developer/Examples/WebKit/NetscapeMoviePlugIn/


One thing I would not recommend is using any of the QuickTime API calls in that plugin, they are laughably out of date. Nor was it obvious, to me, how you add things like JavaScript properties. But it is a start for an XCode project.

And I won't get started on what a sorry state of affairs that something so archaic as Netscape plugins are still used to add functionality to Mac browsers.

Building WebKit on OS X when you have Qt installed

I ran into trouble building WebKit (Safari) on my MacBook. When I entered the command to build it
% WebKit/WebKitTools/Scripts/build-webkit --debug
the build script immediately started complaining about qmake not understanding the "-r" option. This seemed really strange to me as I hadn't thought Safari was a Qt application; it certainly looks much better than any Qt application I've ever seen on the Mac, and I've written 3. It turns out that Safari is not a Qt application but the build script does look for the QTDIR environment variable and will try to build a Qt version if it finds that variable. [Thanks to Mark Rowe on the WebKit team for this information].

So the solution to my problem was to temporarily undefine QTDIR.

% echo $QTDIR
% unsetenv QTDIR
% WebKit/WebKitTools/Scripts/build-webkit --debug


Netscape Style Browser Plugin Development on OS X

If you are creating or maintaining Netscape style browser plugins on the Mac, you must get the nightly build of the open source version of Safari from WebKit.org. As someone who occasionally has been reduced to doing printfs to the system log in order to debug plugins remotely on a 10.3 box, it is luxurious having a debug build of the host application. Just follow the instructions for compiling a debug version and debugging it from XCode; if you have everything setup correctly you can debug the application and the plugin at the same time. Total setup time of less than an hour. It's fantastic.

I've tried to compile Firefox from source (using Visual Studio under Windows) and it was nearly impossible to get a debug build up and running. Actually, I don't know if it is nearly impossible or simply impossible since I gave up after a couple of days. Creating a Safari debug environment is a snap by comparison.

And the WebKit team is unbelievably responsive to bugs you find in WebKit itself. I've reported 2 problems over the last week and both were solved by the next day.

Chroma Keying BMP files in OS X

I've been contracted by Train Player International to help port their TrackLayer model railroad design software to OS X. It has been going quite well, and I'm grateful the proprietor, Jim, has allowed me to apply my theories of cross-platform development, and create a first class Cocoa application. But it is a work in progress, and there are both bugs and unimplemented features.

Regardless of its fragile state, Jim sent our development version out to select users for feedback and to prove it isn't completely vaporous. And feedback we got. Some of it positive, some negative, but the one thing everybody hated was the launch time; it was abysmal on older hardware and not particularly peppy even on my MacBook. I will not tolerate intolerable performance in any app I write, so I've made it my first priority to fix.

It didn't take long to track down the culprit, the reason TrackLayer was taking 13 seconds to launch on my MacBook. I was pre-loading 83 small image files representing train car tops and sides. These files were 24 bit BMP files with neither masks nor alpha channels; they were chroma keyed--a color was set aside to represent blank space--and my code was responsible for converting it to an a form with an alpha channel which could be composited with other images. Here's an example file of the same format:


My code replaced the pink area with transparency. The problem was with my original code to manipulate BMP images. I had even written a comment to myself to say it would be slow and inappropriate for heavy use. The major problem is that NSImages are not easily manipulated; their API is extremely limited in that regard. Basically, there is colorAtX:Y and setColor:atX:y which I had been using to change the chroma key color one pixel at a time:

// don't do this, it is slow
NSColor* clearColor = [NSColor clearColor];
int width = (int)originalSize.width;
int height = (int)originalSize.height;

NSBitmapImageRep *repWithAlpha = [[[NSBitmapImageRep alloc]
initWithBitmapDataPlanes:NULL
pixelsWide:width
pixelsHigh:height
bitsPerSample:8
samplesPerPixel:4
hasAlpha:YES
isPlanar:NO
colorSpaceName:NSCalibratedRGBColorSpace
bytesPerRow:0
bitsPerPixel:32] autorelease];

for(int x=0; x < width; x++)
{
for(int y=0; y < height; y++)
{
NSColor* originalColor = [(NSBitmapImageRep*)anImageRep colorAtX:x y:y];
if([originalColor isEqual:chromaColor])
{
[repWithAlpha setColor:clearColor atX:x y:y];
}
else
{
[repWithAlpha setColor:originalColor atX:x y:y];
}
}
}

It's slow just looking at it, what with the creation of an NSColor object for each pixel. And I needed to come up with something much faster. The problem is there is not a lot of documentation on doing what I want with either NSImages or CGImageRefs. There was this short section of the Quartz 2D Programming Guide, which recommends using the CGImageCreateWithMaskingColors function new to OS X 10.4, but isn't very clear on its use, and that's why I'm writing this blog entry to clear it up.

In order to create a masked image from my BMP, I had to:

• Create an NSImage from the BMP file
• Use colorAtX:y to get the color at the top left corner which I assume is the chroma key
• Ask Quicktime to create a CGImageRef from the file
• Use CGImageCreateWithMaskingColors to create a masked copy
• Convert the CGImageRef to the NSImage I can use

That's right, I create 4 separate versions of the image to get what I need. And it is still more than 10x as fast as the original.


NSColor* chromaColor = [(NSBitmapImageRep*)anImageRep colorAtX:0 y:0];

size_t bitsPerComponent = ::CGImageGetBitsPerComponent(originalImage);
float maxComponent = float((int)1 < < bitsPerComponent)-1.0;
float redF = rintf([chromaColor redComponent]*maxComponent);
float greenF = rintf([chromaColor greenComponent]*maxComponent);
float blueF = rintf([chromaColor blueComponent]*maxComponent);

const float maskingMinMax[] = { redF, redF, greenF, greenF, blueF, blueF };
CGImageRef maskedImage = ::CGImageCreateWithMaskingColors(originalImage, maskingMinMax);


Using this new code dropped the launch times on my MacBook from 13 seconds to under 2; pretty peppy.

I've put together a sample project: ChromaKeyTester.dmg which contains all the code for this, so I hope you Google searchers found what you sought. This only works with the variety of BMPs I needed to open, but it could be made more general.


[UPDATE]
I received an e-mail from a coder with evidently more experience than I at manipulating images in Cocoa. He made a number of suggestions, none of which I found worthwhile pursuing because I'm just not going to get my launch times much faster. I've gotten the launch time on my MacBook down to 1.5 seconds (and this is the worst case, where an image populated document is automatically re-opened, forcing the main thread to wait for the image loading thread to complete). Even if his conversion methods took zero time they could not push the launch time below 0.9 seconds. I realize 0.6 seconds on my MacBook might be 1.2 seconds on a PowerBook G4, but still, it's fast enough.

Still, other programmers might have a more dire need for squeezing performance, so here are a summary of his suggestions with my parenthetical reasons for rejecting them:

• Use a reasonable format like PNG instead of BMP (Can't do this for backwards compatibility. That was the first thing I asked.)
• Skip the reading top/left corner for chroma key color step. (Can't, different images use different colors.)
• My method leaves traces of the chroma key in the anti-aliasing (Sorry, that's just the test image. The actual production images are hand tweaked pixel by pixel with no anti-aliasing. And I could always expand the range of colors masked by CGImageCreateWithMaskingColors. )
• Do the conversion with a Quartz Composer script. (This is a cool idea, but sounds complicated to setup, and could you really load the Quartz Composer framework and execute a script in less than 0.3 seconds or so? Maybe, the Quartz Composer application launches in less than a second, and can merrily load and display my BMPs at a rate limited 60 fps and 7% rendering load.)
• Use a NSCIImageRep--which is a Cocoa wrapper around a Core Image Image. (I had not been aware of this very useful looking object, and this seems the most practical suggestion. If I have the time for extra speed tuning, I will explore this.)
• Get some C or C++ BMP reading code and read and convert the raw data myself. (This would have to be a big win performance wise for me to have to deal with the vagaries of the BMP format myself. And there would be no guarantee of a big win, as Apple's converter code is presumably optimized for Altivec or SSE3 or whatever.)

I will remind myself to read up on using NSCIImageRep and the Core Image framework. It sounds extremely useful.

[Another Update: Turns out there is code in Apple's examples for dealing with converting arbitrary bitmap formats to a reference format: either RGBA integer, or RGBA float. This is in the Tableau example for the Accelerate framework. Look for the message "constructIntegerReferenceImage". You can easily refactor this code to run through the reference image buffer and do your chroma keying before taking the step to create an NSBitmapImageRep].

Upgrading a 4GB iPod Mini to 8GB

I've been watching the DealRAM prices for 8GB Compact Flash modules. My intent has been to upgrade my wife's 4GB Pink iPod Mini which has sentimental value to me (in addition to having what I consider the perfect form for music playing). Well, the price of a solid state Transcend 8GB 120x speed compact module (model # TS8GCF120) just dipped to $100 at one of my favorite vendors: newegg.com, and it became time to pull the trigger. (It's actually become cheaper since I bought mine.)

There are plenty of instructions on the Web for surgically replacing an iPod's hard drive. I went with this instructional video. The only difference was the thinner form of the compact flash module. Also, I had to determine which way to plug the old drive's cable into the CF module. The trick is to look at the rail guides on the sides of the old MicroDrive, compare them with the rail guides on the CF module and plug the cable in maintaining orientation. Also, I reused the blue rubber bumper from the old drive to keep the new module from rattling around. I also took the opportunity to install a new battery.

As for performance, it seems to be working fine. It filled up with 6GB of data over FireWire in a reasonable amount of time (sorry, didn't time it, maybe 20 minutes). It just has a lot more space.

[post was updated for minor fact correction]

[Update: The upgraded iPod has been working fine for 10 months. Today, I installed a 2nd card, a Transcend TS8GCF133, into my own 6GB Silver iPod Mini. The original Microdrive failed and it was either upgrading or trashing. Seems to work just fine.]

Replacement Nipples (for the ThinkPad)

My wife has an X23 series model 2662 IBM ThinkPad. For years, she's avoided using the TrackPoint pointing device embedded in the keyboard as the standard rounded one was extremely abrasive and worn. She'd always attach an external mouse or (after meeting me) a trackball, or when in need using a piece of tissue to protect her finger. Well, dutiful husband that I am, I finally bothered to do a Google search if there was some replacement nipple or eraser tip for her model.

I was happy to find that Lenovo sells an inexpensive ThinkPlus TrackPoint Cap Collection. So for $10 shipped, I bought a variety of replacement caps, and she likes the wide flat type with the rim. Much more comfortable.

MythFrontend and HDHomeRun Wireless on a MacBook

[Update: check out Signal GH, an iPhone utility for monitoring the signal quality of an HDHomerun].

I've been running the MythTV Frontend for Intel OS X several hours a week for the last month. This is on my original MacBook (1.83GHz Core Duo, 2GB RAM) connected wirelessly via a 802.11g router to the basement MythTV server. I'm typically on the couch in the TV room upstairs, or on the bed in the basement; 30 feet from the wireless hub at most.

Performance has been good, and I've been happy with it, but it does lock up if you quit the application directly from Live TV mode. It's an odd sort of lock up in that the video keeps playing, but the beach ball of death cursor indicates the GUI itself is locked. So I'll command-tab out and force quit the application. Of course, the audio is nothing compared to the 5.1 speakers on the actual MythTV, but I have been known to watch even such sound intense shows as 24 on the MacBook, too lazy to watch it properly. Occasional flickers could be wireless instability, noise on the antenna, other processes grabbing the MacBook CPU or packets lost in Ethernet. It's hard to say.

I had worried whether my Ethernet network was up to the task of carrying 2 HD streams down from the HDHomeRun in the network closet to the MythTV (both the PC and the HDHomeRun are 100Base-T, the routers are 1000Base-T and the wiring is Cat-6) while simultaneously streaming a 3rd stream back up the same Ethernet cable to the wireless hub in the network closet. But, this works surprisingly well. I do like to give Live TV a couple seconds of buffer to give it a chance for error.

The GUI actually works better than the Linux version on my desktop, where I long ago lost the overlay GUI in TV mode. On the Mac, I actually see the Paused/Play time HUD window when I pause playback. Interlacing is not as good though.

In preparation for writing this blog entry, I put the MythTV frontend into a small window mode, and I'm just noticing it mirrors the video content in the OS X Dock. This is probably a bad idea, and a waste of cycles. I know it's cool and all, in a 2001 sort of way, but not that cool. Also, the UI for changing the window size is completely lame: holding down the right arrow key while it counts up to 480 horizontal pixels when I have a perfect good 4, 8 and 0 keys is unforgivable.

In summary, MythFrontend for OS X is nice to have, and I'm glad network and computer hardware is finally up to the task of this kind of high bandwidth application.

Be careful with your CFBundleVersion

This post is along the way of a reminder to myself should I ever have to figure out how my application's plist has caused the Launch Services manager to act strangely.

If you accidently setup your CFBundleVersion element badly, by for example, putting it in quotes, you will end up with the Launch Services database treating it as if it had a version of zero. You can see this clearly by running the lsregister utility:
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump

[Update: lsregister has moved in Leopard:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -dump
]

Static Libraries dependent upon static libraries in XCode

Just a helpful hint to try and prevent your wasting time like we did at my day job. We have a large C++ application which has several different levels (Standard, Pro, Ultra....). So to speed compilation and linking, we put large chunks of code common to all the levels into separately compiled static libraries. Thus, we only have to compile that code once every time we build all the applications, resulting in a massive time savings.

Unfortunately, this was not working under XCode as when we linked in our libraries, there was always some symbol or other which was not available, and we ended up putting large amounts of code into the main project and compiling it for each application level (making our build process at least twice as long as it should have been).

My boss finally got so sick of this he spent a couple days tracking down the problem, and it was that our static libraries were dependent upon other static libraries, but those libraries were not linked in until the application as a whole was linked. Somehow, this confused the XCode linker (ld) and it ended up missing symbols. The trick was to link the other sub-dependent libraries into the libraries static libraries and not directly from the main project.

I know the above is confusing. Here's a more graphical description.
(Before)

• Main Project


• Static Library 1 Project (needs Static Library 2 & 3)


• Static Library 2 Project


• Static Library 3 Project

(Now)

• Main Project


• Static Library 1 Project (needs Static Library 2 & 3)


• Static Library 2 Project


• Static Library 3 Project

HDHomeRun - Networked HDTV Tuner

[Update: check out Signal GH, an iPhone utility for monitoring the signal quality of an HDHomerun].

I have a PCHDTV 3000 PCI card in the Dell Dimension which serves as my MythTV. Since DVB drivers became part of the standard Fedora install, it has been problem-free. But, it doesn't meet all of my needs.

First, there are occasions when the broadcast networks show 2 or even 3 good shows at once. I'd like to be able to catch these rare alignments, but my PCHDTV can only record one show at once. I could buy another, but that would be the last open PCI slot in the Dimension, and what if I wanted to expand internal storage later with an SATA card? Second, the MythTV was banished to the basement for excessive noise, which means it is about 80 feet of RG6 cable from the main antenna splitter in the second bedroom, meaning it is getting less signal, and noisier signal than an upstairs device. Third, to be useful, the MythTV has to be on all the time, which means draining a minimum of $9/month of electricity. Fourth, I've never been able to figure how to access a PCHDTV card with non-root level privileges; I'm sure it's possible, I just can't figure it out, which means I run the mythtv backend as root. This is frowned upon.

Then, I came across the HDHomeRun networked digital TV tuner (both ATSC and QAM). This simultaneously overcomes all 4 problems with the PCHDTV.

• It has 2 tuners.
• It doesn't use up a PCI slot.
• It can be located as close to the antenna as I like.
• It can be accessed via any user account with network access.
• I can access the data stream directly from my MacBook, albeit kludgily, even when my MythTV is off. [Update: It is no longer cludgy on the Mac. You can buy an HDHomerun bundled with El Gato's slick EyeTV application.]

It does cost more than a PCHDTV, but less than two.

I held out for a while, but I finally ordered one. It came Wednesday. I've been happy.

MythTV 0.20 has built in support for this device. However, be warned that you have to open your firewall to its traffic. If you try to run mythtv-setup and you can't get it to scan for channels. Maybe it's your firewall.

I was amazed by how well my MythTV box pumped massive amounts of data. At one time, I simultaneously recorded 3 HD programs over the air--2 over Ethernet from the HDHomeRun, and 1 via the PCHDTV--while watching a recording of Day Break from the night before, and it was smooth as silk. There have been a lot of improvements in MythTV over the last year; I don't think it could have taken all this back then on my aging hardware.

Lately, whenever I buy new hardware, I measure it's electrical usage. There is a hidden cost to every gadget we buy. According to my Kill-A-Watt, my HDHomeRun draws 6 Watts at all times, whether capturing or not [Update: I've heard that subsequent revisions (those you would buy new today) use less power] . A low power mode while awaiting network commands would be nice, but the usage isn't bad compared to the 90 Watts the MythTV box draws. So it's less than a dollar a month to power it. However low the power, it does get a little warm, and I worry about it's life span, but time will tell.

In order to control the device from my Mac, I downloaded the hdhomerun_config source code from the Silicon Dust Forum. It was a simple matter to create an XCode project and compile the command line tool for Mac OS X, and I could then use the instructions for using VLC to watch TV directly from the device on my MacBook. Entering a series of obscure command line commands is much too klunky, and I hope VLC will absorb these functions, but it did work and looked great on the 13.3 inch screen.

Dell 2005FPW with the LG LST-3510A HDTV receiver

I have a two year old Dell 20.1" widescreen LCD display (2005FPW). I also have three LG LST-3510A HDTV receiver/DVD players. Just so any Googlers might be curious, yes you can watch HDTV on your DVI capable LCD monitor and this receiver. No, you can't watch upconverted DVDs, at least not with the firmware in this particular 3510A (1.93), it gives me a warning about needing a HDCP connection and refuses to play. HDTV is a little distorted, as the 2005FPW is not a true 16:9 monitor (closer to 16:10), but it looks fine driven at 720p.

I like the 3510A as an HDTV receiver. I bought this particular unit for $49 shipped via an eBay auction, The low price due to the description saying it couldn't play DVDs well. Well, guess what? I don't care. It's a sensitive, reliable, flexible HDTV tuner and that is what matters to me. I can hook it up with DVI, VGA or component connectors to any number of display devices. Plus, it has both coax and optical digital audio connectors. I got another one cheap (not as cheap) with the preferred 1.91 firmware because the seller didn't know how to get it out of Spanish menu mode.

Here's its manual.

As is typical, neither eBay units came with remotes. Luckily, my third unit has a remote. Also, you can get most (not all, the DVD arrow keys are wrong) of the functionality from a cheap One-For-All remote. The One-For-All even has the codes for a proper fast forward/reverse on the DVD player, which the original remote does not have. Even the Harmony remote database has a few holes, so I'm glad to have at least one master remote.

Actually, I have little clue how people choose the proper eBay price for one of these things. I just saw an auction close for $58+shipping on a unit which was clearly marked as broken and being sold for salvage/repair. But it did come with a remote.

I don't really need 3 HDTV receivers. This third one is a family gift.

XCode debugger exited with status (1)

All of a sudden an XCode project which I was sharing with a collaborator refused to be debugged. The debugger was evidently exiting unexpectedly with "exited with status (1)" message. 

It took a long while to figure this out, but the project had been modified by my collaborator to hard code ppc generation. There were 3 such references in the project file. Had to change that to get the debugger to work again.