Fix for Netatalk nbp_rgstr: Connection timedout error

So, I had been playing around with VMWare Server in my Gutsy installation and when I restarted, my Netatalk daemon was failing with an error: nbp_rgstr: Connection timedout.

Luckily, I found this old forum post, which had the solution: Just go into your atalkd.conf file and uncomment the line that says eth0.

I'll walk you through it:

Open a terminal, then type:

sudo nano /etc/netatalk/atalkd.conf

Then delete the # sign in front of the word 'eth0'. Pretty simple!

Apparently, netatalk will just bind to whatever network interface is laying around, so it can sometimes get confused and bind to the crippled one used by VMWare Server. This fix just tells it to look for eth0 from now on instead of picking one willy-nilly.

CPU-optimized Backend for gHandBrake

Edit: The original author of gHandBrake's site appears to be down and I haven't heard from him since I submitted code to add most of the advanced x264 options to the interface, so I decided to offer my updated version right here (64-bit binary plus source code) until further notice. If you need to compile it for a 32-bit system, I have a list of dependencies for HandBrake here, and precompiled binaries of Yasm Debian/Ubuntu systems here. If you have any problems with any of it, just let me know in the comments and I'll try to help.

You can also download the unmodified gHandBrake (fewer features, but more stable) here. This package includes both the source tarball and a precompiled 64-bit deb binary for Ubuntu/Debian users.

Original post: I've been trying out gHandBrake, the excellent new GTK frontend for HandBrake. It's very early in development, so it doesn't have many of the advanced options--such as advanced x264 options--implemented yet but it seems quite solid and will eventually be a great replacement for HandBrakeGTK/RippedWire, which is basically just an incomplete port of the Windows GUI (of note, HandBrakeGTK does not actually pass advanced x264 options to the commandline).

Unfortunately, the precompiled binaries offered by the author do not appear to utilize HandBrake's processor-specific optimizations, so I decided to offer an optimized 64-bit build of the backend that would:
Download link

To use it, just download and extract, then replace the old ghandbrake-backend with the newer version. In a console, you would type (assuming it was extracted to your desktop):

sudo mv -f ~/Desktop/ghandbrake-backend /usr/bin

Since switching to the updated backend, my average encoding speed went from ~40 fps to ~115 fps, but YMMV.

Of course, if you compiled gHandBrake yourself from source, you would already have the optimizations included as long as you had the yasm assembler installed when you compiled. If you want to go this route, I have a precompiled yasm binary that recognizes SSE3 instructions in my previous post.

Please leave me a comment if you have any questions or concerns.

HandBrake 0.9.2 and yasm 0.7.1 precompiled deb binary for 64-bit linux

Update (5/15/09): The binaries on this page are woefully out of date, but I have working binaries built from the latest code available in my PPA repository. Directions for adding it to your package manager are available here.

Download: HandBrakeCLI-AMD64 0.9.2 (Thanks Alexander!)
Download: yasm-AMD64 0.7.1
yasm-i386_0.7.1 (it's in a tarball, but the deb is inside)

I just got finished doing some building for HandBrakeCLI. They used to provide a precompiled 64-bit binary on the official site, but they've stopped for some unknown reason, so I decided to provide a copy of my own.

This binary doesn't need to be installed. Just navigate to the directory that contains it and type

./HandBrakeCLI

followed by any desired options (for more information on using the command line with HandBrake, visit the HandBrake wiki).

One of the biggest pains in compiling HandBrake (other than the lack of a comprehensive list of dependencies) is the fact that, to get the most out of HandBrake's processor-specific optimizations, you have to have the yasm assembler installed. Unfortunately, the version in Ubuntu's repos only supports instructions up to SSE2.

To correct this, I had to download and compile a newer version of yasm (namely 0.7.0) before I built HandBrake. Once I got that going, HandBrake recognized my cpu's extensions and accelerated the encoding speed to approximately 3.5-4x faster than the stock, non-yasm compile.

This binary should recognize any extensions present on my cpu: an AMD X-2 4000+ cpu, which has all the usual goodies up to SSE3 (so you fancy-pants core2duo users are out of luck on the SSSE3). Edit: A fella named Alexander was kind enough to supply a build with additional support for SSSE3 and Cache_64. Thanks Alexander!

My binaries include the original source code, which I have not modified. If you have any problems with them, please leave a comment or drop me an email and I'll see if I can correct the problem.

Hardy Never Worked, So I'm Back On Gutsy

As awesome as Hardy is, I could never get those damned random freezes I mentioned in my last post to stop, so I had to default back to Gutsy.

Fortunately, there were a few things I learned about integrating with Mac OS X 10.5 Leopard while fiddling with my Hardy install that are perfectly applicable in Gutsy, including screen sharing and networking with Netatalk.

Screen sharing was surprisingly easy to set up. Simply install xtightvncviewer from the repos:

sudo aptitude install xtightvncviewer

This should get make your Linux box accessible from your Leopard box, and you can also use it to control your Mac from Linux by typing into a linux terminal:

xtightvncviewer your.Mac's.IP.Here

You will likely have to enter some sort of password to gain access. There are also some command line options you can use to optimize your experience, which you can see by typing:

xtightvncviewer -help

If you plan on using screen sharing often from your Mac, you should consider adding a link to the program to your Dock. It's just a regular program located at /System/Library/CoreServices/Screen Sharing.app.

On to networking:

I had previously used Samba to network my Macs with my Gutsy/Hardy box because I had always heard it was the easiest method. This simply isn't true. All it takes to get things going using Mac-native networking is to bring up a terminal and type:

sudo aptitude install netatalk

If you're on Leopard, you will run into the issue of it not liking cleartext passwords, which the Netatalk version from the Ubuntu repos happens to use. To fix this, you can either do it the hard way: by recompiling a new version of Netatalk from source with a special option enabled, or you can do it the easy way: by jumping on your Leopard machine and open up a Terminal and type (all on one line, courtesy of a commenter at macosxhints.com):

defaults write com.apple.AppleShareClient
afp_cleartext_allow -bool true

Now Leopard will happily communicate with the standard Netatalk from the repos. As a word of caution: this method is less secure than the 'hard way,' but I just needed it for my home network, so it's not a big deal to me.

If you want shares to be accessible to your Mac from your Ubuntu box, you'll have to add them to the end of the file /etc/netatalk/AppleVolumes.default (ex. /media/sda1 at the very bottom of the file) and then restart netatalk by typing into a terminal:

sudo /etc/init.d/netatalk restart

Hardy Heron Headaches

Update:I've installed an alpha build of Intrepid Ibex, the next Ubuntu version after Hardy Heron, on a separate partition and I haven't had any weird freezes. I haven't given it as rigorous a test as I probably should, but it appears to be okay. This leads me to believe the freezes I was experiencing were caused by the kernel version that shipped with Hardy (2.6.24), which is known to be buggy and unstable on many systems. Intrepid, on the other hand, uses 2.6.27, which seems to be rock-solid. I believe you can manually backport the 2.6.27 kernel to Hardy using Prevu, an automated backporting utility, but my system was so buggy I doubt it would have made it through before it crashed... Instead, I intend to just wait another month or so and install Intrepid when it gets an official release.

I upgraded my HTPC from Ubuntu Gutsy Gibbon to the new version, Hardy Heron, a couple of days ago and it's been quite a headache, considering this is an LTS version. As a caveat, I have been using the 64-bit version, which is known to have more issues since it has a smaller user base.

First, I tried upgrading through the update manager, which was a dismal failure. I was sort of expecting that to happen, though, so I wasn't too put off.

Next, I burned an install disk and set to installing. From the start, the install window was grossly oversized for my monitor (an HDTV) so I had to spend a few minutes shrinking it down to a usable size. It wouldn't allow me to make it small enough to fit the screen, though, so I had to do a lot of scrolling during the install. After that admittedly minor hang-up, the install process went fine.

Upon reboot, I ran into my next problem: GRUB tossed up an error 22 when I tried to boot my system. However, I found that I could get it to work by going through a goofy song-and-dance of first selecting my Windows partition (which also failed to boot) then going back and selecting the Hardy partition again after Windows failed. Not the best solution, but whatever.

Once I booted up, I replaced my user folder with my backed-up user folder from Gutsy, which worked swimmingly. However, my storage drives (SATA, formatted to FAT32) were not automounted like they were in Gutsy, which was a bit disappointing. After some mucking around in /etc/fstab, however, I was able to get them going properly.

All was well for a few hours until I started getting random freezes. These weren't regular ol' crashed X-server freezes, either. They were hard freezes that killed the mouse/keyboard and wouldn't resolve without a hard reboot. I tried looking in my kernel log and didn't see any panics or anything like that, and they started getting closer and closer together, so I made the decision to wipe and reinstall.

This time around, I made myself a separate /home partition in case I ran into any more catastrophic issues. Again, the window was sized wrongly, but everything with the install was fine other than that.

This time around, I guess GRUB got its act together because Hardy booted on the first try without needing any coercion. I haven't checked my Windows partition yet, though, so it may still be borked.

The reinstall seems to have fixed my random freeze issue, but I ran into a really bizarre issue about 3 hours after finishing installing: my colors were all wrong (yellows were blue, etc.) during video playback but not on the desktop.

After some searching, it appears this is an old issue that may be related to proprietary binary drivers and may have something to do with gstreamer doing some sort of hue correction that is redundant with what the driver is doing with newer cards (I have a GeForce 8600GT). The solution for me for the most part was to open Totem and go to the preferences and set the Hue slider all the way to the left. However, I actually use VLC for my videos, so I also had to fix that program separately.

For it, I had to go into the Preferences>Video>Output modules and switch the Video output module from 'Default' to 'X11 video output'.

Not to knock the Ubuntu devs, though, because they have done a wonderful job adding new features and making a highly polished OS. In fact, I've had as many or more problems with my recent upgrade to MacOS X 10.5 Leopard. In my next post, I'll go over some of the fun I've had integrating the two systems in my home network.

Update: I believe I've tracked down the source of my random freezes, which have returned since my reinstall. I used my Leopard machine to ssh into my Hardy machine and just left top running as I went about my normal activities so whatever was displayed when the next freeze came along might tip me off to the issue. Apparently, smbd (the Samba file-sharing daemon) was spawning processes left and right, causing the system to become unusable and eventually freeze. I uninstalled Samba and it seemed to fix things up. Unfortunately, my server is pretty useless without being able to share files, so I set about installing Netatalk, the Apple filesharing protocol. Interestingly, *it* (in the form of afpd) began spawning processes like crazy and shortly froze up the system as well. It looks like I'm share-less until I can figure this out. If anyone has any ideas, feel free to leave a suggestion in the comments.

Using the cat Command To Hide Files Inside Other Files

cat is a standard command from Unix operating systems, such as BSD and Mac OS X, and Unix-like operating systems, such as Linux, that can be used to concatenate and display files. In this tutorial, I'm going to teach you how to hide any file inside any other file using cat, such that no one will every know the hidden file is there. This obviously has a number of uses, including providing another layer of protection for sensitive information such as bank numbers, personal information, etc.

WARNING: this is an advanced trick that requires the use of the command line. If you are scared of using the command line, don't bother continuing.

Ok, now that that's out of the way, pick a file you want to hide and another file you want to hide it in and place both files on your desktop. In my case, I'm going to hide an archive
inside a picture

Next, open a terminal. For Mac users, go to Applications => Utilities => Terminal.app; for Linux users, you'll have to find out where your particular distro puts it. Switch to your desktop:

cd Desktop

Now, we're going to perform the cat command:

cat archive.rar >> 1.jpg

Now my archive file is concatenated to the end of the picture file. If I double-click on the picture file, it will open in my picture-viewing program without any indication that it is abnormal in any way. However, as you can see from these before/after pics:

the picture's file size is now much larger, thanks to it having the archive attached. Anytime you want to access your hidden file, just rename your file to the hidden file's extension and open as normal:



Note: If you plan on hiding anything really important in a file using this method, I also suggest using some sort of encryption, in case someone actually finds it. This obfuscation just adds another layer of protection for your information.

How To Backup Your DVDs using DVDShrink

The most common question people ask me is how to backup commercial DVDs (which usually come in DVD-9 format) for burning to regular, run-of-the-mill blank DVDs (DVD-5 format). There are many ways to accomplish this, but one of the easiest is to use DVDShrink. It's a closed-source program that's available for Windows users, although Linux users (such as myself) can run it effectively through WINE.

Step 1

The first step is to download DVDShrink. It's pretty easy to find and you can download it here or here. After that, double-click the installer; the default options should be fine for most users.

Step 2

After you've installed DVDShrink, open the program. You should get a window that looks something like this:



Next, click the "Open Disc" button at the top and select your DVD drive from the menu (usually the D: drive in a standard Windows environment):



DVDShrink will now begin analyzing your DVD. This usually takes around 2 minutes. You can uncheck the box labeled "Enable video preview" if you are worried about spoilers:



Step 3

When it's finished analyzing, you should end up with the DVD structure in the left panel and some compression options in the panel on the right, like this:



Next just click on the "Backup!" button at the top:



You should get a menu like this:



From the "Select backup target" pull-down menu, select "Create ISO image file" and then click the "OK" button:



This will make an exact copy of your DVD, shrunken down to fit a single-layer DVD. There are many other options you can fiddle with in DVDShrink, such as removing sound from menus or reducing the quality of unimportant features to improve the quality of the main movie, but they're not really *necessary* so I'm not going to cover them here.

When DVDShrink finishes encoding, you should have an image file (ends in .iso) that will fit on a standard 4.7GB single-layer DVD. To burn it, you need to use an external program with image-burning capabilities, such as Nero or Alcohol 120%. I personally use the shareware demo version of a program called DVDSanta available free from various places, including here.

If you get this error:

then your DVD uses an unusual copy-protection mechanism that DVDShrink cannot bypass. If this happens, you'll have to rip the DVD using another program first, such as DVD Decrypter, and then use DVDShrink to resize it (Note: this error may also appear when running the program through WINE. Thus, Linux users are encouraged to use DVD Decrypter first).

Copyright notice: using this method to rip commercial DVDs, even if you own them, may be prohibited in your country. It is best to research the laws in your locale before following these steps.