However, I noticed recently that the wrong share for the NFS server would get mounted on the client. Getting the wrong share mapped to a local mountpoint really messed up the operation of apps on the client.

While I didn’t find this exact problem being discussed, I noticed that some people have been taking a slightly different approach to specifying the NFS shares:

Note the absence of the “/share/HDA_DATA” portion of the share name. Since I had not attempted this approach for quite some time, I thought I’d try it.

So far, so good. I’ll report back if this approach as fixed the issue. I also plan to update our Mac OS X clients to take this same approach. Simpler is better.

This post addresses how I routed the fog lights. After installation and coding, here are the very bright fog lights in action:

Removing Trim Parts
The instructions supplied by Europrice were very clear and sufficiently addressed how to remove the rear side interior trim panels to access the vents for routing an extra wire from each outer unit and to route the drivers side extra wire under the rear load trim section over to the passengers side and the BCM unit.

I had read in various forum posts about routing the extra wire from each outer unit through a grommet in the rear body panel, but using the body vents seemed to be a lot easier route that probably won’t have any adverse impact.

Several photos of routing the outer lights’ extra wires through the body vents.

Two mistakes I made:

1. I removed the metal sill protector trim even though it appears that I only needed to remove the underlying plastic part.
2. Since I did not wear gloves when removing the metal trim stip, I cut my finger. Doh!

In the following photo, the metal sill protector is shown removed (ignore the blood). I believe I could have just removed the entire black plastic still on the sill without removing the metal sill protector.

The sharp edged metal load protector

Routing outer left wire under sill trim

The underside of the load trim after I reinstalled the metal sill plate.

Fog Light Wires
Although wiring the fogs is optional and I am not often driving in conditions to warrant using the rear fog lights, I figured it would be best to ensure they worked and that I didn’t end up with a dead switch on the dash.

The good news is that removal of the rear hatch plastic trim and some additional trim pieces went off without a hitch. As is often the case with interior trim removal, the lower rear hatch trim required quite a bit of force to remove it. Being relatively new to the disassembly process, I was pretty concerned about breaking parts.

I fished the longer of the two loose fog wires from the left side inner tail light area around the rear wiper motor and joined it up with the shorter loose wire on the right side. Then I routed the two wires together along the existing wire harness running up the right side of the rear hatch. I was concerned about the skinny trim piece being able to cover the extra wires, but it worked fine.

Yellow wire is extra required for fog light

I didn’t have instructions for removing the next set of trim pieces, but it was relatively easy to figure out. First, I popped off the trim from the right side hatch hinge. Next, I determined that I needed to remove the lateral trim piece at the rearmost portion of the headliner. This trim simply pops off from the rear. Its removal exposes the rear hatch motors.

The following photo shows the lateral rear headliner trim removed, but it was taken during reinstallation of the trim. Note the yellow fog light wires already installed.

Once this lateral trim is exposed, you’ll see a screw holding a portion of the D panel trim in place. In addition to this screw, I believe I removed at least one, perhaps two, additional screws from the sides of the D panel trim such that I could bend the D panel trim and fish the wires back down to the BCM area where the connections are made. The nice part of this approach was that I did not need to remove the entire D panel.

The following photos are looking down on top of the partially removed D pillar trim. The fog light wires are fished from left to right toward the BCM/fuse box location.

The following photos show how I ran the fog light wires through the bottom legs of the large u-shaped hatch trim.

Few More After Pics

Very bright fogs!

Close up of left fog:

Running lights (David coded them to act as DRLs):

Colors are washed out, but turn signal (top), brake (middle) and running light:

Brake, reverse and running lights:

Note reflector on inner portion of outer light unit. OEM 2010 US lights did not have this reflector.

Man, I am really liking these lights!

Read more to see the Perl script.

The Perl script is included below. Overall, it relies on two source of current conditions data:

• Data obtained from a MySQL database populated by thermd.
• Forecast data from the National Weather Service for our specific location.

You can also download the attention getting beep file.

• Announce the weather alert twice and then be quiet for a period of time
• Override the quiet period when a more severe alert occurs

I’ve also published the current source code for people to leverage.

Updated Logic

Here’s how the latest version of the script works:

• Given the severe weather alert feed for our area, it grabs the latest feed data.
• Loops through all items in the feed looking for either thunderstorm or tornado warning alerts. Since we don’t care about bothering the occupants with watch announcements, we ignore feed entries for watches.
• When it finds a warning alert of interest:
  • Check whether we think an alert is already in progress. We simply use two files in /tmp as flags.
  • If an alert was already seen, determine whether the previous alert needs to be downgraded or upgraded
    • If so, get rid of the old alert
  • Else, check to see if the quiet interval (30 minutes for thunderstorm warning and 15 minutes for tornado warning) has elapsed
    • If quiet period has elapsed, get rid of the old warning alert
    • If the quiet time has not elapsed, exit the script
  • Record the alert type for future reference (as a file in /tmp)
  • Build the alert text that will be read over the ceiling speakers
    • Note the tweaking for certain text strings.  These are done to improve the quality of the spoken announcement.  Through experience, we found that some edits made a big difference.
  • Announce the alert twice

In addition to announcing the alert over our ceiling speakers, it would probably be useful to send a text message to our mobile phones.  For example, when we’re away from home, it would be useful to be alerted that our area is under threat. Since we have other apps sending texts to our mobile phones, I can probably tackle that aspect with a few more minutes of hacking.

The Script

Since I am a Python newbie, don’t be too hard on me for the quality of the following script.

And the associated crontab entry which calls the script to poll the NWS every two minutes:

The Ingredients

There are two audio files representing the initial attention getting beep following by the standard severe warning alert sound.

As you’ll see in the script above, we’re using the swift command line tool from the Cepstral text-to-speech package.  See my earlier posts referenced above for more information on that package.

Update

Since we recently replaced our 24″ iMac with a newer 27″ model, I had to migrate EyeTV to the new system. In doing so, I encountered a few issues that my original instructions didn’t address. These are:

• Hard disk name: Our previous iMac had a hard drive name of “HDD”, but the standard name on Mac OS X is “Macinstosh HD”. Since the RecordingDone-called.scpt makes a reference to the hard disk, you might also need to make this adjustment. I’ve updated the code below to reflect the more standard name.
• VLC: This time around, I installed VLC for Mac. I believe you will also need to do so in order to get the proper codecs installed.
• EyeTV Archive folder: By default, EyeTV appears to place it under your Documents folder. In my case and in the scripts here, I went into to the Preferences of EyeTV and reset the archive location to just under “Macintosh HD” or “/EyeTV Archive”.
• Transcoded folder: I manually created this folder under the “EyeTV Archive” folder.

EyeTV

Although Mac nerds have been using EyeTV for years, I hadn’t been very aware of it since we already had satellite TV service and a digital video recorder (DVR).  At about $90 USD, the EyeTV One product is a great combination of a simple USB-based device and a companion application called EyeTV.  In our case, since we don’t expect to watch much live TV, and certainly not on our iMac in the kitchen, the best part is that the app enables you to write custom scripts to process recordings.  This was a key feature for us because once a show was recorded, we wanted the recording to automatically become available to a variety of devices.

The EyeTV One dongle has a USB connector on one end and a threaded F connector for standard coaxial cable on the other.  You simply connect your OTA antenna lead and plug the dongle into a USB port on your Mac.  (Similar devices exist for Windows PCs). Once the EyeTV software is loaded up and you configure the channel guide, you’ve got yourself a relatively inexpensive DVR.  By default, the EyeTV software records videos in broadcast or “lossless” quality (often 720p) to fairly large .mpg files.  Although it’s easy to configure the EyeTV app to automatically add recorded shows to iTunes, we didn’t depend on this feature due to the following issues:

1. Location of video files: Both the original large .mpg files and the transcoded files remained on the local drive. My goal was to get the transcoded files to our NAS server. I could have configured the EyeTV app to save both the original and transcoded files on our NAS server, but then both the recording and transcoding steps would have occurred over our network.  Not a desirable situation given the processing overhead and size of the files.
2. Lack of control over transcoding: You don’t have much control over the built-in transcoding process. I wanted to ensure that the resulting videos looked good when displayed via Apple TV 2 on a large screen TV.

The Challenge

My challenge was to take recordings made through the EyeTV software and make them available on a variety of devices: iPad, Apple TV 2, and several UPnP/DLNA-capable devices such as a Sony PS3 and a Samsung BD-C5500 Blu-Ray disc player. I knew that we wouldn’t necessarily watch recordings on all of these devices, but, as you’ll see, the solution described below made it pretty easy to do so.

Beyond the manual scheduling of show recordings via the EyeTV app, my requirement was to have the following post recording steps taken care of automatically:

• Transcode video files: On the iMac, transcode the fairly large lossless .mpg files created by EyeTV to smaller sized .mp4 files with H.264 encoding.
• Move to NAS server: Move the transcoded .mp4 files to our NAS server thereby saving space on our iMac and making it easy to share the video files via a variety of devices.
• Add to iTunes library: Add the .mp4 files to our main iTunes library so as to enable easy access from our Apple TV 2 and to ease loading videos on the iPad for road trips. When adding videos to iTunes, include metadata such as show title, episode and description whenever feasible.
• Make available via UPnP server: Ensure the .mp4 files are added to our UPnP media server so as to enable easy access from UPnP-capable apps and devices such as our Samsung Blu-ray player, Sony PS3 and the AirPlayer app on the iPad.

The result of adding shows to an iTunes library would look something like the following screenshot. Only one or two shows in the screenshot have description metadata because I recently added that feature.

The Approach

The key to the solution was to insert the right custom scripts into the EyeTV TriggeredScripts directory such that EyeTV would execute my code whenever a recording completes:

Library/Application Support/EyeTV/Scripts/TriggeredScripts/

As long as the script file names conform to the names known to the EyeTV app, the scripts will automatically be called at certain points in the scheduling and recording process. In my case, I was only interested in the RecordingDone stage of processing. Hence the presence of a RecordingDone.scpt file in the screenshot below.

The second file shown below, RecordingDone-called.scpt, is not invoked by EyeTV. Rather, my custom RecordingDone.scpt calls this helper script. I’ll explain why this is done shortly.

Both of these scripts are written in the AppleScript scripting language. AppleScript was new to me, but given my technical and development background, it was pretty easy to learn enough about it to complete these scripts. I was especially impressed by how easy it is for AppleScript developers to interact with apps. As you’ll see in the example below, it was simple to interact with the EyeTV, Finder and iTunes apps.

Role of HandBrake

Since transcoding the large .mpg files into more manageable sized files was a key interest, I once again turned to the popular HandBrake application for transcoding work. I was already familiar with using the HandBrake GUI based on my recent DVD ripping project. This time around I also installed the HandBrakeCLI wrapper such that I could easily invoke HandBrake from the command line within AppleScript.

Hurdles

Transcoding lossless .mpg files can take a long time. Especially when using a 2-year old iMac. Given that transcoding may take more than an hour, it wouldn’t be uncommon for multiple recordings to be in the queue or being processed at the same time. So that was one problem: How to avoid hanging up the EyeTV app’s thread that calls the RecordingDone script while potentially multiple transcodings might be outstanding.

Another problem was with the time it takes in our environment to copy 1-4+ GB files from our iMac to our NAS server. Depending on the circumstances, this could take at least several minutes.

Asynchronous Transcoding and Copying
I addressed the first problem by having the RecordingDone script call the RecordingDone-called script in a non-blocking manner. This means that the RecordingDone script will complete almost immediately and return control to the EyeTV app while the RecordingDone-called script does all of the heavy lifting: transcoding using HandBrake and copying the resulting .mp4 file to our NAS server. The result is that multiple executions of the RecordingDone-called script can be running at once.

This was a little bit tricky because I was new to AppleScript and wasn’t sure how to call an AppleScript from the command line and pass the necessary arguments. But it turned out to be pretty straightforward.

AppleScript Timeouts
After having addressed the blocking issue, I ran into AppleScript timeouts during both the transcoding and copying steps. A bit of digging led me to understand how to manually set timeouts for sections of AppleScript code. Once I put in some reasonable caps, the timeout issues went away.

The AppleScript Files

RecordingDone.scpt

Here’s the script that is called by EyeTV whenever a recording completes. This is a pretty simple script that calls the RecordingDone-called script in a non-blocking fashion. The use of the “&” at the end of the command is the magic that makes it a non-blocking execution. The recording ID passed from EyeTV is sent along to the RecordingDone-called script as a command line argument. This ID enables the called script to interact with the EyeTV app later on to obtain more information about the recorded show. e.g. the location of the original lossless recording, show title, episode, description, etc.

If you would like to unit test the RecordingDone script, you can rename it, make several recordings and then call the renamed script directly from a terminal window like this:

$ osascript RecordingDoneTest.scpt 2

Where “2″ represents the second recording in your list.

RecordingDone-called.scpt

This where the real action occurs. The key steps are:

• Transcode from lossless .mpg to .mp4
• Copy to NAS server and remove original lossless and local .mp4 copy, then empty Trash
• Add to local iTunes library

A few highlights of the code:

• HandBrake preset: Learning from our earlier experience with HandBrake, we again chose to use the “Apple TV 2″ transcoding preset.
• Dealing with empty episode strings: Since not all shows have episodes, the script checks whether the episode info is empty. If it is, then we use the recording date as a qualifier in the .mp4 file name. Otherwise, recordings without episode information would overwrite one another.
• Special characters in file name: When building the .mp4 file name, we call a function that cleans up any special characters so as to avoid incompatible characters in file names and to generally make the file names more friendly. See the Credits section at the end for the source of the clean function.
• Timeout settings: I may have gone overboard in some of the settings, but they’ve been working well.
• Hard to understand path names: I still don’t have a great handle on how the path names related to our mounted folder from our NAS server are working in the Finder section, but they work!
• Proper M4V attribute: Learning from our past experience with the subtle attribute settings for video files and how they’re important to iTunes, we use Finder to set the proper attribute.

End Result

It’s actually pretty cool and useful to have recorded shows be made available automatically across a wide range of devices. With the typically closed and proprietary DVRs from satellite companies, we’d never have this degree of freedom. Being able easily watch a show with the family in the living room or choose to watch the same show on the iPad or one of the other UPnP-capable devices is quite useful. Although we haven’t been on any road trips since I set up this process, I expect that we’ll be loading a few shows and movies directly to the iPad for trips

On the technology front, earlier versions of these scripts have been running for a little over a month. With the most recent tweaks to add show metadata, I think the process is pretty stable and should not require much care and feeding. The main thing I’ll have to work out is how we can easily remove shows that have already been watched and we don’t need to retain. However, since we recently expanded our NAS server’s storage capacity, removing shows is less of an issue.

Since I tackled playing of .mp4 movie files from our home server’s MediaTomb UPnP server as part of the DVD ripping project, the .mp4 show files resulting from this EyeTV project play without issues via our UPnP-compatible devices including the AirPlayer app on the iPad, the Sony PS3 and the Samsung BD-C5500 Blu-ray player. Even XBMC on our hacked Apple TV 2 can plays the videos through MediaTomb.

Here are a few screenshots of the TV shows being made available on the Apple TV 2 device.

First, the overall Apple TV 2 screen showing the shared iTunes library on the right. Our kitchen iMac is serving up this library.

Next, the types of media served up by the iTunes library:

Finally, a specific show with description metadata:

Next Steps

• Clean up debug and output file handling. Currently, execution of multiple jobs will overwrite previous job’s file.
• Consider integrating CommSkipper or similar commercial skipping features such that commercials are automatically removed from show recordings. Tried it once briefly, but ran into issues. Might try it again.

Credits

• Some initial thoughts came from this forum post.
• Cleaning up file names.

Overall, it was a pretty simple process and relatively inexpensive.

Since the VCDS program only supports Windows, we used an installation of Windows 7 64-bit in the bootcamp partition of our MacBook Pro to install and run the application. The one hiccup was that the version of VCDS that came with the cable did not include a 64-bit Windows 7 driver for the cable.  After resolving that problem by using the 7-Zip utility to extract the driver file from a newer version of the installation .exe file, everything worked fine.

The few customizations we made are outlined below.  The steps reflect the menus and settings in the VCDS program.

The car in the following video isn’t ours, but it shows the before and after behaviors of some of the mods listed below.

Daytime Running Lights (DRLs)

This one simply keeps the LED daytime running lights (DRLs) lit when either turn signal is active. From the factory, the LEDs will “wink” or be turned off on the side on which a turn signal is activated.

Operate Windows and Sunroof From Key Fob

Makes it possible to open and close the windows and tilt the sunroof by continually pressing the unlock and lock buttons of the key fobs.  This mod might be useful to air out the car when walking out to the car on a hot Summer day. Once the following code is set, you have to go into the MMI menu for the Car settings and enable the window down capability on the windows of interest.

Ambient Interior Lighting

This one is a bit more involved, but it’s pretty cool to have adjustable footwell lighting that is controllable through the MMI screen. Again, courtesy of AudiEnthusiasts.com.

Emergency Blinking Brake Lights

When brakes are applied heavily, brake lights will blink at a high rate. We have not yet tested this change.

Gear Indicator in Drive and Sport Modes

Normally, only D or S is shown in the driver’s information area, but with this modification, the gear number will also be displayed.

Gauge Needle Sweep

Just a cool eye candy feature. Again, the following video is from another owner’s car, but it shows both this feature and the next one, the lap timer and oil temperature display.

Lap Timer and Oil Temperature

We might not use this feature much, but it will allow us to have a stopwatch readily available if and when we ever need one. The oil temp gauge might be nice to check the temp on really warm days.

Front Fog Lights Remain On With High Beams

Video in Motion

A more involved hack, but it enables playing a DVD when the car is in motion. From the factory, you can only play a video when the transmission is in park. We haven’t tried this on a road trip just yet, but I am skeptical as to whether our son will be able to see the screen well enough from the back seat.

Instructions are here.

Many tech savvy people have been doing this sort of thing for years, but I’m glad that I finally got around to trying it for myself.  The results have been worth it: Not only are we able to easily access our 70 odd videos from all of the devices mentioned above, it helped set the stage for our use of EyeTV to record over the air (OTA) digital TV broadcasts and store them on our NAS server.

The Ingredients

After several hours of research and trial and error, I arrived at the following solution using tools on Mac OS X:

• RipIt to make a descrambled backup of the DVDs to a filesystem (~$22USD)
• Handbrake to encode the ripped DVD content to m4v format files (free)
• MetaX and tagChimp to add cover art and other metadata to the m4v files (free)
• iTunes to make the movies available to iOS devices including Apple TV and iPad

We also use Ubuntu Linux, but it was so much easier finding the necessary ripping and encoding tools for Mac OS X.

We’re using MediaTomb on our Ubuntu-based home server to act as a DLNA/UPnP player for the non-iOS devices. On our iPad we’ve installed the AirPlayer app to stream content directly from our home server.

Storage Strategy

Even encoded and compressed video files can take up a lot of space: depending on the resolution selected, it’s not uncommon for a movie to consume 1-4 GB of storage. Consequently, this exercise of backing up our DVD collection caused us to expand the overall capacity of our NAS server.

Since the ripping, encoding and metadata tagging processes are so disk and CPU intensive, it made sense for us to perform all of these operations on our relatively recent MacBook Pro and then copy the finished files over to our NAS server for back up and streaming.

On our NAS server, we carved out a new “videos/” folder with separate subfolders for “movies/” and “tv/” to hold the backed up DVDs and any shows we record through the EyeTV OTA dongle on our iMac.

Making a Back Up and Descrambling

RipIt was well worth its modest price as compared to my experience in trying to use several Linux tools.  Out of the box, RipIt is simple to use: insert the DVD, quit the Mac OS X DVD player and click “Rip” to back up and descramble the content of the DVD. A typical DVD on a fairly recent MacBook Pro might take 20-30 minutes to back up.

The resulting package can be opened in HandBrake for encoding to a smaller footpring .m4v file compatible with Apple iOS devices and devices. RipIt also supports compression, but we opted to use the more feature rich HandBrake tool to encode and compress the video files.

Although we have a handful of Blu-Ray DVDs, we haven’t yet backed those up because RipIt does not support Blu-Ray and we didn’t have a Blu-Ray DVD device available.

Encoding

The next step is to use HandBrake to encode the backed up DVD images to a more space efficient file format suited for the devices on which we’ll play the content.

• Install VLC: First, I installed VLC as a prerequisite for HandBrake.  Among other roles, VLC provides the ability to play the content contained in the ripped DVD images.
• Load ripped DVD: Then I fired up HandBrake and clicked on the Source icon in the toolbar to select the recently ripped DVD image from my desktop.  HandBrake reads all of the titles from the DVD image before allowing you to select which one you’d like to select.  In almost all cases, I’ve just used the default selected title.  However, in those situations where multiple videos are stored on one DVD, for example, with the Dune DVDs, you need to select each of the large titles separately to perform to encodings.  You can get a good feel for which title to select by looking at the time duration next to the title number.
• Select preset: I then clicked on the Toggle Presets icon in the toolbar to show the device-oriented presets.  I chose “AppleTV 2″ because it seemed to have most of the settings of the High Profile preset, but it’s obviously going to work well for the Apple TV 2 device that we have in our living room. Thus far, the audio and video resolution settings with this preset have offered the best compromise by supporting both large displays such as our TVs and smaller ones such as the iPad.
• Add more to queue: Since the encoding tasks can take an hour or more per DVD, I got into the habit of adding multiple DVDs to the queue and letting HandBrake run over night.

Adding Cover Art and Metadata

Much like various MP3 encoding tools are able to add metadata (song title, album art, etc) to ripped music files, MetaX can be used to do the same for movie video files.  As with HandBrake, MetaX includes a queuing feature to enable you to add a bunch of video files to a queue and process them automatically one after another.

The key hurdle I encountered with MetaX was initially getting black video content after applying metadata.  It turns out that, given the resolution of and resulting size of the backed up video files, I had to select Preferences -> General check “Enable Support for Large Files” to address the problem.  Even through most of the video files were under 4 GB in size.

Apart from that issue and its sometime quirky handling of checkboxes (the Toggle button in the toolbar is really useful in this regard), MetaX is pretty easy to use:

• Select file: Open up the .m4v or .mp4 file of interest and wait for MetaX to find metadata from the tagChimp online database.
• Select and customize metadata: Select the tagChimp matches and review the metadata to see which one best suits your needs. In some cases, I made the following tweaks:
  • Under the Sorting area, I often overrode the default sort key to ensure that the video was sorted the way we liked it in our video players. For example, I changed the sort key from “The Dark Night – Batman” to “Batman – The Dark Night” such that all of the Batman movies would appear next to one another.
  • Once in a while, I overrode or added cover art by finding an image on Google image search and dragging it to the cover art area.
  • On rare occasions, I had to redo or fill in the Chapters information.
• Add to queue: Hit the “+” button under the list to add another selection. Don’t worry, you don’t have to save your prior track’s selections.
• Write and share the metadata: Once you’ve queue up the tracks of interest, hit Write & Share to both add the metadata and share your modifications with the tagChimp database.
• Enjoy the cow: When the queue is finished, MetaX will play a nice cow sound.

Using with iTunes and iOS Devices

OK, so now that we have all of these .m4v files, how do we share them with Apple iOS devices? Not surprisingly, the key is iTunes.  As long as the movie files are added to an iTunes library, you’re able to easily load them them on iPads, iPhones, iPod Touches, etc and stream them to Apple TV 2 devices.

As with most homes that have a Mac, we have multiple user accounts that run iTunes. In our case, we selected one account on our kitchen iMac under which we added all of our music tracks and videos to the iTunes library. We can choose to sync various iOS devices to this iTunes library in order to load movies and music. For example, if we’re going on a road trip, we might chose to load a few movies and TV shows from the iTunes library to the iPad.

Since all of our music tracks and video files are stored on our NAS server, we configured iTunes to NOT copy files to the iTunes media folder when adding content to the library. The library still has an entry for the files of interest, but iTunes will leave the content of the file on the NAS server.

Adding a movie file is pretty simple: select File -> Add to library… and browse over to the NAS server to select the file of interest.  As long as the file is compatible with iTunes, you should see it appear in the Movies section of the library.

Streaming movies to Apple TV requires iTunes to be running on your network and Home Sharing to be enabled.  Once this is done, the Apple TV device will be able to browse and play all of the movies known to the iTunes library.  Although I’d rather not have to depend on iTunes to play media from our NAS server, in practice it hasn’t been much of an issue.

Using with non-Apple Devices

This whole back up business for DVDs got me into the mode of exploring which UPnP/DLNA server would work best for our other players such as a PS3 and Samsung Blu-Ray player.  The goal was to be able to play our movie collection and recorded shows from all of these devices.  Even the iPad has a selection of DLNA-compatible apps such as AirPlayer that enable one to stream content directly from a server without having to worry about iTunes.

Although I tried multiple UPnP/DLNA players including the built-in TwonkeyMedia player on the QNAP, few of them worked properly with our Samsung Blu-Ray player.  In the end, I had the most luck with installing MediaTomb on our Ubuntu-based home server system which in turn accesses the media content on the NAS server. How we customized the MediaTomb configuration to work with the Samsung Blu-Ray player will be the subject of another blog entry.

Although none of the UPnP compatible media players displays the movie metadata as well as the Apple TV, they are all able to play the content housed on our NAS server.  Chalk one up again for the quality of the proprietary Apple experience, but it’s also a win in the openness category for the open source-based and standards compliant UPnP/DLNA implementations.

Next Steps

After having addressed the DVD back up topic, I was ready to tackle how to automatically load into our NAS server and iTunes library TV shows and movies recorded through an EyeTV OTA dongle attached to our iMac.  My next step is to post a blog entry on that experience.

The mission

Take a full image back up of our Ubuntu 10.04 server system that is currently running on an 8 GB SSD.  Replace the 8 GB drive with a 30 GB SSD and restore the image.  Sounds pretty easy, eh?

Backing up the current disk image

The Clonezilla site has detailed screenshots of most of the following process.  I chose default setting throughout the process.

• First, I downloaded the Clonezilla Live CD image and burned a live boot CD.
• Next, I shut down the Ubuntu server and rebooted it using the live CD.
• I choose the Device Image option to back up the entire /dev/sda internal drive.
• On the side, I had a 200 GB HDD US drive enclosure at the ready to act as the destination of the back up.
• I chose the destination to be a local device (I had tried to point Clonezilla to our NFS-based NAS server, but I didn’t have a share set up to be compatible with the /home/clonezilla directory requirement).
• When prompted to do so, I plugged in the USB drive and Clonezilla recognized it.
• I selected the USB drive as the destination and the /dev/sda internal drive of the home server as the source.
• Then Clonezilla did its thing by completing the imaging in about 20-30 minutes.

Swapping in the new drive, restoring image

After Clonezilla completed its back up, I replaced the internal SSD with the larger 30 GB unit and fired up the server with the Clonezilla Live CD. I basically performed the opposite of the back up process above by selecting the restore options.  Again, the process was pretty simple.

Fixing things up

After I booted up the server with the reimaged and larger drive, the one thing that as amiss was the size of the root partition.  It was still only 8 GB or so.  I had been expecting it to have grown to 20 something GB.  What to do?  After digging around a bit, it dawned on me that I should be able to boot up using one of the Ubuntu Live CDs and use the Disk Utility or Partition Editor to grow the root partition.  Once I booted up using an older Ubuntu 9.04 Live CD, I was able to delete the swap partition, grow the root partition and create a new swap partition.

After rebooting the server again, the only change I had to make was to update the UUID in /etc/fstab for the newly recreated swap partition. The blkid command helped me determine the UUID for swap under /dev/sda2.  A quick edit of /etc/fstab and another reboot confirmed that all was OK.

Taking another image

Once I verified that the server was running as expected, I shut it down, booted up using the Clonezilla Live CD and took an image of the new SDD.  Resulting in two backed up images on our USB drive: one from the 8 GB SSD and this second one from the 30 GB SSD.  However, this time the back up or save image process encountered a lot of read-related errors, but the back up eventually completed.  I have not yet verified whether the backed up image will result in a proper restore.  When I can make some more time, I’ll dig into the error situation and try another back up.

Next steps

Over time, I probably won’t take image back ups of the server until I make significant changes to the server.  Especially since all of the important data is housed on our NAS server. For example, since we now have a lot more space available on the home server, I’d like to apply a wholesale update to 10.04.  As I do this, it will be nice to know that we have two backups that we can fall back to in case the update process goes awry.

The other thing I’d like to do is figure out how to back up to and restore from images housed on our NAS server.  Then we could remove the USB drive from the loop and have the side benefit of the image back ups being backed up to multiple drives in our three-drive rotation scheme.

We have since updated to firmware version 3.3.0 Build 0924T, a version that includes built-in support for Time Machine. I figured why not try out the built-in support and move away from the earlier command line-based approach.

How We Use Time Machine

Generally, we don’t really care about recovering individual files through Time Machine.  We mainly use it as an  insurance policy in case one of the drives fails or in those cases where we opt to upgrade to a larger drive.  We’ve used it in the latter situation with great results.

Enabling Built-in Support

Compared to the command line magic of our earlier use of Time Machine with the QNAP device, the built-in support makes Time Machine set up a breeze. Simply:

1. Access Time Machine under the Backup folder of the web console
2. Mark the Enable checkbox
3. Enter a password to use on the client machines
4. Provide a quota to limit how of much of the NAS server’s capacity to allocate for Time Machine backups
5. Hit Apply

This process will automatically enable the AFP file sharing protocol service on the QNAP because that’s the only protocol supported by Time Machine clients.

Client Setup

Simply go into the Time Machine area of  System Preferences and select Select Disk…  You should see the TMBackup share listed.  Once you select this disk, you’ll need to enter the password you set when enabling the Time Machine feature on the QNAP. Optionally, click Options… to exclude certain folders from being backed up. For example, you might want to exclude the Downloads folder of each user’s account. Finally, move the Time Machine slider to On to activate the Time Machine client.

Back Up Now

You can click on the Time Machine icon in the system notification area and select Back Up Now to initiate a backup immediately.

After you back up for the first time you’ll see your client’s back up area appear under the Time Machine portion of the QNAP admin console:

One Hiccup: Problems Connecting to AFP Share

After initially configuring the built-in Time Machine support, we encountered periodic error messages when attempting to enter the Time Machine app on the clients. An AFP connection error would occur, but eventually we’d be able to access the Time Machine app. The scheduled back ups worked fine. Lately, we haven’t seen this issue reappear.

Restoring Files

Although we don’t typically use Time Machine to restore specific files, the user interface to do so is pretty cool.  Simply click on the Time Machine icon in the notification area and select Enter Time Machine. You’ll see a series of Finder windows representing the state of your files at each back up point.  You can right-click any file to restore it from that time.

Restoring Complete Drive

We’ve done this at least twice with our iMac: once to ensure that the process worked and once after we replaced the internal SSD with a larger capacity unit. In both cases, the process was simple and worked as expected. The process is pretty straightforward: boot from the Mac OS X install DVD and launch the Disk Utility to perform a restore from a Time Machine share.  Of course, you’ll have to format a new drive before performing the restore, but otherwise it’s a straightforward operation.

Adjusting Backup Schedule

Apple’s Time Machine is hardwired to back up every hour.  This is overkill for our needs. As such, we installed Time Machine Scheduler, a third party program to exert more control over the backup schedule.

You can specify the back up interval and periods of the day during which back ups will be skipped. Using this program is a bit confusing as it disables Time Machine and takes over scheduling of the backups.

In four months of using this app, we’ve had good luck with it.

Original Drives Started to Fail

Since one of the three original 500 GB drives failed late last year, I was also motivated to replace the two remaining three-year old drives in our three-drive rotation scheme. Given that the two active drives – one internal and one external – run 24×7, it didn’t surprise me that the original drives were starting to have issues.

When one of the original 500 GB drives failed, I opted to purchase a single 1 TB Western Digital WD10EARS-00Z5B1 unit as a relacement.  I chose the “green” drive because I knew the TS-109 wasn’t a blazingly fast device to begin with and I wanted to see if the “green” aspect would further reduce power consumption.

Even though I had replaced one of the external 500 GB drivers with a 1 TB unit, our overall NAS server capacity was still limited to 500 GB due to the size of the internal drive.

1.5 TB or 2 TB?

Although the latest TS-109 firmware supports 2 TB drives (we’re running firmware 3.3.0 Build 0924T), I had read too many complaints about the 2 TB version of this model line even outside of the context of using them in QNAP devices. Since the 1 TB WD10EARS drive seemed to work fine for the past several months and seemed to be quite cooler to the touch than the prior drives, I purchased two 1.5 TB WD15EARS-00MVWB0 units at $75 USD each through Amazon.

How About a New and Faster NAS Server?

I briefly considered purchasing a newer NAS server to achieve a dramatic performance boost, but I chose not to bite the bullet now because the QNAP has been so reliable and contains all of the functions we need from a home NAS server.  Yes, performance could be a lot better, but we haven’t had any issues with streaming videos to various devices around the home.  Large file transfers can take more time than I’d like, but we rarely perform such tasks in real-time.  Plus, our off-site rotation scheme has worked brilliantly and I’ve appreciated the flexibility of how we can have diverse drive capacities in our setup as drives inevitably fail and are replaced with newer units with larger capacities.

The Replacement Approach

If you’re using the Q-RAID 1 quasi RAID feature then task of replacing the internal drive is supposed to be quite simple:

• Open up the NAS server and remove the internal drive.
• Install in the NAS server one of the external drives that had been sync’d using Q-RAID 1.
• Reboot and you’re done.

Since we already had our 1 TB drive attached externally and sync’d, I opted to start by replacing the 500 GB internal with the 1 TB external.  As advertised, the replacement and reboot went off without a hitch.  Once rebooted, all of the settings and data were intact and our overall capacity was doubled from the earlier 500 GB internal drive.

The next step was to place one of the new 1.5 TB drives into the eSATA drive caddy, format it using the QNAP web console and apply the Q-RAID 1 syncing feature to it.  This process also worked as expected.

Future: Swap 1 TB Internal with 1.5 TB External

Although we doubled our NAS capacity from 500 GB to 1 TB, it will be easy for us to replace the 1 TB internal drive with one of the 1.5 TB drives in the future. However, as we consume more than 1 TB of the internal 1.5 TB drive, we wouldn’t be able to use the 1 TB as an external drive.

Summary

All in all, this was a great experience that further reinforced my positive impression of the QNAP device and overall quality of their firmware.  I’ve read about issues concerning various apps and NFS performance, but for the really important basics of backup and restoration functions, I am very pleased with the device.