Vandenberg Delta launch photographed

Got up this morning to photograph the launch of a Delta II rocket from Vandenberg AFB from the new upper deck at Silver Home. When the light hits the rocket’s trail in the dark, it can be really spectacular. Conditions weren’t right for that phenomenon this morning, but we were still able to see a rocket stage burnout at 6:14am.

_MG_8818

Here’s Michelle on the upper concrete pad after the launch had come and gone.

_MG_8823

Here’s what we were hoping to get (Michelle’s photo from 2005):

22sept2005vandenberglaunch9

DLNA is not a total loser

I doomed myself by saying that streaming from my Mac Pro to the Sony Playstation 3 was working extremely well. A few days later, it was completely broken. Here’s the story.

The ingredients: two houses with home theater equipment, a collection of movies on DVD, a variety of computers available, an Apple TV, and a PS3. The discs can’t be in both places at once, so I ripped them to hard disk for use in one house, and stored all the discs at the other house for playback there. I am interested in the extras found on many DVDs, not just the feature, so I was careful to rip all the video selections on each disc. I kept them organized with a folder for each product (one disc or multiple). For TV series collections, I’d include an episode number in each filename so they could be retrieved in chronological order. The extras for each product I’d gather together in a folder named Extras and give them sensible filenames. The idea was to bypass the awkward silly menu structure imposed by the DVD authoring and just have access by reasonable names to each significant piece of video.

The resulting collection filled up most of two terabyte external Firewire drives, after re-compression. There was no settop box available with that much storage, at least none at a reasonable price. So, I needed a way to play the video from the external drives. I leave my Mac Pro on all the time, so the obvious solution was to leave the drives mounted on the Mac Pro and stream the video to the living room on demand.

OK, it’s a Mac, and Apple generally does a superb job of getting user interfaces right. So the obvious solution was an Apple TV, streaming from iTunes on the Mac Pro. Total and complete disaster. iTunes was happy to import everything from my complicated directory structure, and to serve it up on demand to the Apple TV. As a flat list. One, single, very long flat list in ASCIIbetical order. That meant that under ‘M’ in the list I had six separate things named “Mission Overview” (yes, I have all the Star Trek series on DVD). Episode 01 of every season of series sorts together in the list, before any of the Episode 02 files. Just a hideous mess.

Waiting through a couple of major revisions in Apple TV software didn’t help. Take Two, then 3.0, still lame. Now, I’m sure this is the right design for some class of user. If you have a few dozen titles and you keep only the main movie from each disc, maybe this is very nice. But it doesn’t match my requirements.

Going down the Apple TV route, I could either keep waiting for Apple to change its design to suit my needs (which seems increasingly unlikely as Apple TV converges on a design that seems more and more oriented toward the iTunes Store), or hack the Apple TV with third-party software. I know there are options available from third parties, and as a reasonably serious computer guy I’m not too intimidated by the prospect of a complicated conversion process. I could make it work, but I never did. For one thing, I wasn’t looking forward to devoting the time it would take to evaluate the various third-party options. For another, I do like the way the Apple TV handles music, and I didn’t want to screw that up. Nonetheless, I was just about ready to dive in, because I needed a way to have convenient access to all that video.

Somewhere in the middle of this drawn-out process, Blu-ray happened, and I bought a Sony Playstation 3 as a Blu-ray player. I was distracted from the DVD archives for a while by newly-purchased Blu-ray movies, and didn’t pay too much attention to the other capabilities of the PS3.

A few weeks ago I happened to upgrade the software in the PS3, just because there was new software available. After installing the upgrade, I again perused the menus to see if there was anything new and cool. I didn’t find anything new of interest, but I did notice again that the PS3 had a way to look for a video server on the network. Hmm! I wondered if it was any less lame than the Apple TV. I didn’t think it was likely, but it might be worth a try.

A quick research session on the Internet taught me that I needed a DLNA server, and that a well-respected one for the Mac was MediaLink from Nullriver. And hey, I already had it licensed and installed on my machine, from some previous experiment with video streaming. I fired it up and pointed it to the two external drives, and went back downstairs to see what it looked like on the PS3.

There it was! The PS3 had already automagically detected the MediaLink server and tagged it Potato, the host name of my Mac Pro. If I just clicked on that, I’d find out just how awful a job the PS3 software would do with my media. Click. It showed me the names of the two drives. Click on one of those, it showed me the top-level directories on that drive. In fact, the whole directory hierarchy I’d painstakingly laid out — and Apple TV promptly flattened — was there to browse. That’s exactly what I wanted. The browsing was even pretty snappy, over my wired Ethernet.

What’s more, the video playback worked, without much annoying delay or any glitches. Even fast forward was smooth and predictable, so I could skip the horrendous theme music when watching episodes of Enterprise. Life was good. And then I made the mistake of saying so, and the very next time I tried to stream video, it failed utterly to work.

Maybe this was a problem introduced by the new PS3 software, and with a little luck Sony had already fixed it. I checked for another new version. Sure enough, there was another update. I let the PS3 update itself and tested again. Still busted.

Maybe this was a known problem with MediaLink — I was running an old version, after all — and Nullriver had already fixed it. I downloaded the latest version of MediaLink, 2.0b1 (a beta release) and installed that, after figuring out that it installs as a preference pane and not as a regular application. Another test, another complete failure.

Oh, the PS3 could still see the MediaLink server. It still showed up tagged Potato. But when I attempted to browse the server, the PS3 claimed “There are no titles” and in the upper right corner, a message box appeared heralding “DLNA Protocol Error 7531”. Wow, what a user-friendly error message. For a translation, I turned again to the Internet, but I didn’t find much in the way of specifics. A lot of people were having random-seeming problems with DLNA protocol errors, including number 7531, but nobody seemed to have much of a clue what exactly it meant or how to fix it.

Well, no problem, right? I can just look up the DNLP specification and find out what that error code is defined to mean. No, I can’t, because the DNLA protocol specification isn’t public. It costs $5000, and I can only imagine what kind of agreements I’d have to sign before I’d even be permitted to pay. In any case, I doubt there’s a lot of precision in the definition of error codes even in the full spec.

With the spec unavailable, I gleaned what I could from various articles discussing DLNA. One particularly useful post was Why do I hate DLNA protocol so much? by Ben Zores, author of GeeXBoX, an open-source Linux-based media center software distribution. From Ben’s rant I learned that at the bottom of multiple layers of directory service and connection management cruft, all that’s really happening is that the server is providing the client with an HTTP URL from which to stream the media.

Armed with that information, I fired up Wireshark to trace the network packets going between Potato and the PS3. Every 60 seconds, I saw a short TCP transaction, a single query and its response. Here’s the query from the PS3 to Potato:

GET /MediaServer/DeviceDescription.xml HTTP/1.1
Host: 192.168.1.74:9386
Date: Sat, 12 Dec 2009 08:20:37 GMT
User-Agent: UPnP/1.0
X-AV-Client-Info: av=5.0; cn="Sony Computer Entertainment Inc."; mn="PLAYSTATION 3"; mv="1.0";

This makes a lot of sense. The PS3 is identifying itself, and asking for something called /MediaServer/DeviceDescription.xml — a generic-sounding name, so it’s probably straight out of the protocol spec. Notice that Potato’s IP address is 192.168.1.74. You can’t see it here, but the PS3’s IP address is 192.168.1.64, so both are on the same subnet with a netmask of 255.255.255.0.

The response from MediaLink on Potato to the PS3 consisted of a similar header followed by a 55-line XML document. Here’s the header:

HTTP/1.1 200 OK
Content-Type: text/xml; charset="UTF-8"
Content-Length: 2229
Connection: close
Date: Sat, 12 Dec 2009 08:20:36 GMT
Server: Mac OS X/10.x.x, UPnP/1.0, Nullriver HTTP Server/3.0

So far, so good. The Mac OS X server is responding and is going to send a 2229-byte XML response. Here’s the first few lines of the XML:

<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
	<specVersion>
		<major>1</major>
		<minor>0</minor>
	</specVersion>
	<URLBase>http://192.168.179.1:9386/MediaServer/</URLBase>

Whoa. Look at that IP address given as a hostname in the URLBase tag. It’s 192.168.179.1. That’s not Potato’s IP address, and it’s not even on the same subnet. If MediaLink is telling the PS3 to get its media from that address, it’s no wonder it fails to work!

So, where the heck did that address come from? Googling that particular IP address didn’t reveal anything special. I tried putting that URL from URLBase into my browser, not really expecting to get a response since I knew there was no route to any such subnet on my network. But there was a response, and it was just the kind of terse and somewhat cryptic response you might expect from a server that’s expecting to respond to a specialized client program. I tried trimming off the filename part and submitting just the IP address to the browser, and got the standard Apache web server response for an unconfigured server. Some computer, somewhere on my network, was somehow being reached by this URL and responding!

When you already have Wireshark open, every networking problem looks like a job for packet tracing. So I set up a Wireshark capture filter to log packets to and from the mystery address 192.168.179.1, and set the trace in motion. Nothing. I repeated the browser access to the mystery server. The access succeeded again, but still no packets were logged by Wireshark. I threw the Wireshark capture filter wide open and tried again. Still, no packets to or from 192.168.179.1 were logged.

OK, that leaves just one thing. When you start a Wireshark trace, you have to specify which physical interface is to be traced. Potato has only one physical network interface active, the first wired Ethernet port en0, so naturally I was tracing on en0. The mystery host must be on some other interface, somehow. The command to list network interfaces is ifconfig, and that’s the next thing I ran.

That told the story: ifconfig showed an interface called vmnet8 that was using the IP address 192.168.179.1. In fact, vmnet8 was listed before en0. I speculated that MediaLink was enumerating the IP addresses of the available ports, and choosing the first one it found.

Another resort to Google quickly revealed that vmnet8 is a virtual networking port installed as a kernel extension (kext) by VMWare Fusion. VMWare doesn’t try to dynamically load it as needed, it just leaves it installed forever to clutter up your kernel. The VMWare Fusion on Potato was a long-expired demo version I didn’t need, so I simply uninstalled it. The vmnet8 port disappeared, without even a reboot. Repeating the trace of packets between the PS3 and Potato, I could see that the URLBase in the XML file had changed to 192.168.1.74, Potato’s IP address on en0, as expected and desired. (If you’re having this problem and need to keep VMWare Fusion around, I don’t know what to suggest other than to complain to MediaLink for a way to specify which interface or IP address it tries to use.)

I ran downstairs and found that I could again browse the server file hierarchy on the PS3. I declared victory and went straight to bed, it being long past bedtime by then.

The next day when I had a bit of time on my hands, I decided to take advantage of my newly repaired video streaming to watch an episode of Enterprise. It didn’t work. The PS3 couldn’t even see the server. OK, maybe I had left the server shut down in my groggy state the night before. I went upstairs and restarted it. Now the PS3 could see the server and browse the hierarchy again, yay. So I fixed some lunch and sat down to watch. Hit Play and nothing happened for a few seconds. Then the PS3 changed the title of the video I wanted to watch to “Corrupted Data” and returned to the hierarchy browser. Nothing would play. Arrgh. This time the error in the upper right corner was “DLNA Protocol Error 2110” or “DLNA Protocol Error 2101”.

This time Google found me a specific answer when I searched for error 2101. I learned that there was a new problem with the alpha version 2.0a1 and beta version 2.0b1 of MediaLink, having to do with sending thumbnail images to the PS3. It crashes the background program MediaLinkHelper.app, which is the actual DLNA server program, which I confirmed by examining the system log in Console.app. Once the server crashes, of course nothing works. The solution given is to delete the plug-in that tries to handle thumbnail art, /Library/PreferencePanes/MediaLink.prefPane/Contents/Resources/MediaLinkHelper.app/Contents/PlugIns/AlbumArtTranscoder.mltranscoder. I did that and tested again.

My episode started to play, hurray! After the teaser was over and the theme music began to play, I hit fast-forward, as usual. The picture froze and went silent. That’s not how the fast-forward looked and sounded before, and it’s not an improvement. I hit play. I expected to get video, either with or without having skipped ahead by the amount it should have been fast-forwarding. Instead, I continued to hear silence and see a frozen screen, for quite a few more seconds. Before I did anything else, it eventually did start playing, having fast-forwarded ahead about the right amount.

Failing to find anything about this problem with Google, I assumed it was a bug in the beta version of 2.0 that I had “upgraded” to. I foolishly did not save the version 1.54 (I think) that I was originally running. Fortunately, Nullriver makes available version 1.72 for customers who are running Tiger, since the 2.0 versions require Leopard. I downloaded version 1.72 and replaced the beta version with it, and got back the nice, smooth fast-forward behavior I had before.

Once again I have declared victory, and I was able to watch my episode of Enterprise without any additional problems. So far.

Near the Ground at Balboa Park

I found myself at Balboa Park yesterday, because the museum store at MoPA was having a closing-down-for-renovation sale. It was an absolutely perfect day at the park, thanks to a warm Santa Ana wind blowing in from the desert. Besides purchasing a stack of photography books at up to 70% off, I happened upon an open rehearsal of the San Diego Youth Symphony and thoroughly enjoyed lurking at the back of the room while they worked on music for a concert on Feb 15. I even recorded a few bits of it on my iPhone, and the recordings came out surprisingly well, considering.

At the rest break in the middle of the rehearsal, I went to my car and swapped the two heavy bags of books for one heavy camera bag. After rehearsal, I wandered around the park a bit and made a few pictures. Not as many as a typical Balboa Park photo shoot. When I examined the pictures today, I discovered there was a recurring theme in most of them: they show people near the ground.

Since any photography can be turned into Art by sufficient explication, the existence of this theme is crucial to the artistic integrity of my new short subject, Near the Ground at Balboa Park.

Rain Chain enhancement

Part of the recent renovation of my San Diego house was the addition of a short length of rain gutter, to protect the front door (and people approaching said door) from excessive splashing. I didn’t do this last time because there is no good place for a downspout for this gutter. Since then, I’ve learned about rain chains. A decorative chain hangs down from the gutter to the ground, and rainwater runs down the chain.

This works, as I’ve seen at my Palomar Mountain house. But it wasn’t really working in San Diego, as I found out when we finally had a rainy day. The rain wasn’t clinging to the chain, and the ground at the base of the chain was eroding away because I hadn’t protected it.

So, today I installed two enhancements. At the top, I installed a sort of funnel to further encourage the water to hook up with the chain instead of free-falling to the ground. At the bottom, I put down some rocks.

Now I just need another rainy day to find out whether it worked.

Here are the rocks:
_MG_1917.jpg

And here is a look up into the spout at the end of the rain gutter. You can see a sort of star-shaped opening — that’s the bottom of the new funnel.
_MG_1918.jpg

TinyURL Considered Harmful

Back in late 2006 I wrote the following as a letter to the editor of Motorcycle Consumer News. They printed it, and stopped using TinyURLs! One small lurch forward.

To: editor@mcnews.com

I wish you wouldn’t use tinyurl.com in the magazine, for a number of reasons.

First, any error in a tinyurl code makes the link completely useless. This might be a printing error in the magazine, or a typing error on the subscriber’s part. Either way, there’s no way to guess where the link was intended to go.

Second, a careful computer user is very reluctant to visit a web site “blind” without any idea of where he’s going. Tinyurl makes that sort of reckless behavior mandatory. Even if we completely trust the magazine to vet web sites for safety, any typing error and we could end up anywhere on the web.

Third, the reader may not be sitting in front of the computer as he reads the article. If there’s a real URL on the page, he at least has a chance of remembering what web site was mentioned, so he can find it later when he’s at the computer. Likewise, when reading the magazine he may recognize the URL as one he’s already visited, saving a trip to the computer entirely. There’s no chance of remembering or recognizing a tinyurl.

Fourth, occasionally the writer will succumb to the temptation to give a tinyurl without ever even mentioning the actual company or product he’s referring to. This renders the whole reference completely useless unless the reader is at a computer and able to type in the tinyurl correctly.

Fifth, tinyurl.com could disappear without notice, or turn evil somehow, and where would that leave you? All the tinyurl links in a subscriber’s collection of back issues would be obsolete.

I realize that full URLs are too big to fit nicely in narrow text columns in the magazine. I would suggest that there’s a perfectly good standard solution to problems like this one: footnotes. Instead of a tinyurl, put something like [Link 1] in the text, and put the link at the bottom of the page. You can let it span multiple columns in order to minimize line breaks within the URL. The footnote reference is even more compact than the tinyurl, and the full URL at the bottom of the page avoids all of the disadvantages mentioned above.

Thanks for listening.