The Case

I use an Antec Overture 2 desktop ATX case.  It’s a fairly large case, but it fits nicely in my entertainment center.  Unfortunately, it vents out the sides and is a tight fit, so I had to do some modifications to give it better airflow.   I removed the back of my entertainment center where the box is (a virtual necessity given the number of cables hanging from it), and also cut a hole in the side leading from one compartment to another so the vent from the power supply would go somewhere.

Antec Overture II Case

The Processor

Athlon 64×2 4400+ on an MSI K8N-Neo4 Platinum motherboard - the processor is overclock slightly, so it runs at about the speed of a 5000+.  You can’t get either of these anymore because it’s a socket 939 setup.  It goes to show you don’t need a beast of a Core i7 processor to run MythTV.  It has 2GB of Dual Channel DDR ram.  Certainly not anything overly spectacular, but pleanty for running a combination Front End/Backend MythTV setup.  While viewing 1080i HD the processor maxes out at about 60% utilization of a single core.

Capture Devices

Analog cable is captured using a WinTV PVR-250 PCI card.  The card is getting pretty old, being the first part of MythTV I bought, but it still works like a champ.  I capture HD Cable using an HD HomeRun.  I only have the most basic of cable, just enough for broadcast and a few other channels, so the HD HomeRun can capture everything.

Silicon Dust HD HomeRun Networked HDTV Tuner

I can’t stress how great the HD HomeRun is for capturing OTA or QAM unencrypted cable.  It’s a small box, about the size of a few DVDs stacked, with two coax inputs, and an ethernet output.  These boxes have virtually zero configuration, and because it just speaks a simple network protocol, you don’t need to worry about kernel changes or drivers.  The HD HomeRun just works.  Additionally, because it takes up no slots in the computer, you can go with a much smaller form factor system.  This works nicely for my eventual goal of putting everything on a Mac Mini or comparable tiny system.

Storage

Inside of the Overture 2 I have two 320GB hard drives running as a mirrored pair.  This is where my database, photos, and music live.  For recordings I have a 1st generation Drobo with 2×1GB and 2×320GB drives in it, providing about 1.6TB of protected space.  The Drobo is another great device that if you’re serious about MythTV you should strongly consider getting.  Some folks will complain about the noise, but I’ve never noticed the Drobo make any notice.  Although, as a disclaimre, I have two fairly large fish tanks in my living room that produce significant noise.  HD actually doesn’t need that much bandwidth and the Drobo can easily supply enough over USB for all of my needs.  As the limiting factor in the system is the USB bandwidth, you’re safe going for slightly slower, quieter, and cooler drives like the Western Digital GreenPower drives.

The DROBO USB Storage Robot

Display

Inside the Overture 2 is an nVidia GeForce 6600LE.  It’s fanless and really underpowered, I won’t want to play games on it or anything like that, but at the time, it was a decent card to have, unfortunately, it doesn’t support VDPAU, so at some point it will probably have to go.  This is connected via a DVI->HDMI cable to a Sharp Aquos 32″ 720p display.  I realize the videophiles are laughing at me because it’s a small TV, but the picture is quite good, blacks are black, no overscan, etc.  The display is driven at near-native resolution of 1366×768.  This means I lose a 1 pixel strip on each side.  I’ve never actually noticed that.

Remote Control

Currently I use the remote control that came with the WinTV PVR-250 and the attached IR dongle.  It’s been supported just as long as the WinTV card has and it works well enough.  There are some strange quirks where sometimes it seems to fall asleep and needs to be “woken up”.  In addition, it only accepts IR codes from Hauppauge remotes.  The HD Homerun also has an IR receiver that is more generic and should work with most remotes.  I haven’t gotten a chance to play with that yet, however.

Future Upgrades

For my current cable signal, it seems as though this works quite nicely.  If I were to add components to my MythTV box in the future it would most likely be a Hauppauge HD-PVR once I get a better selection of cable channels.  At that point, there is a good chance I’ll reture the PVR-250 card and switch to a much smaller case with everything external.

MythTV has developed very slowly since then.  Each new release brings support for a few more capture cards, and maybe some small new features, but it’s slow development, especially in the user interface category leaves me feeling like I’m stuck in 2003 still.  With some luck, the upcoming release of MythTV 0.22 will change that.  In fact, MythTV 0.22 could really rock your world, and here is why:

Hauppauge HD-PVR Support

MythTV remains one of the best choices if you want to capture high definition video.  The excellent support for pcHDTV cards, and the even better support for the incredible HD HomeRun, make it trivial to capture over the air or unencrypted cable high definition signals.  However, once spot where MythTV cannot compete with Windows Media center is for premium cable channels.  MythTV will never be able to support cable card tuners  because of the closed environment that these external tuners live in and the current requirement that the tuners be locked to the PC they’re purchased with.  So while it’s perfectly easy to watch NBC and CBS in high definition, your hopes of being able to watch HBO or ESPN in high definition are slim at best.  Luckily, Hauppauge has developed an excellent solution that fits the needs of the MythTV user perfectly.

The Hauppauge HD-PVR model 1212

The Hauppauge HD-PVR is a USB component video capture box that transcodes signals up to 1080i to H.264 video in real time.  On a technical level this means that you take the analog component (YPbPr) output of your cable TV box and it feed to the HD-PVR which will then re-digitize the video.  Quality snobs will note that this results in an extra stage of decompression and recompression which leads to artifacts, and they’d be right, but luckily the quality of the box is pretty good, so only the most discerning eye will notice a different in video quality.  HD-PVR support will be included in the next release of MythTV.

QT4 and New Theming

MythTV is probably one of the last programs on the planet that still uses QT3 as it’s widget set. It’s a reliable widget set, with moderate theme capabilities, but it was clearly designed for desktop applications.  You can change the color and appearance of widgets, like scroll bars, buttons, and drop down menus, but it doesn’t have the ability to provide nice transitions between screens or widgets.  Basically, you’re working with a static widget set.  Sometime, probably a couple of years ago, MythTV introduced support for OpenGL screen transitions.  Now when I go from the main menu to my recordings screen, a nice transition happens, but on the screen I’m still using the same static screen with no transitions or interactivity.  Several times on the mailing list people have brought up how subtle transitions and audible feedback would really add to the experience — after all, TiVo didn’t succeed because it was the most feature filled, it succeeded because it had the best user interface.  Currently the closest thing that MythTV can do is run an external program that plays a sound when a key is received by the application.  I’ve tried it, and it’s just not quite right.

QT4 should fix many of these issues.  Nokia didn’t purchase QT to sell the widget toolkit as another system for creating desktop applications, they intended to use it in embedded applications where things don’t always look the same.  The new features of QT4, which was released way back in 2005, really make it a top notch widget set.  In particular, the entire toolkit has been abstracted to work nicely with OpenGL, allowing for better transition effects, theming and mapping of graphics.

Watch out for the Trippy Pink Floyd Shit around 1:40

When combined with the longstanding ticket to create and have all widgets use libmythui, this means that effects will be getting a much needed overhaul.  Including smooth transitions on sliders and small amounts of sound effects.

VDPAU Support

Although PCs have gotten much faster since MythTV first arrived on the scene, MythTV can still tax your computer, especially when watching HD content and doing other things in the background.  It’s fairly normal for me to watch an HD program as it is recording, record another HD program, flag previous recordings for commercials, and transcode content all at the same time.  You can play with nice settings and realtime threads to ensure the playback never skips a beat, but that’s difficult, also you’re ignoring the fact that most modern video cards have video decoding acceleration built in — effectively allowing you use your CPU only to push data across the bus, while the video card decodes and displays the video.

This support is nothing new, it’s been around for a while in the form of XvMC.  Unfortunately, unless you’re using a Via or Intel chipset, which are not common in standalone MythTV boxes, you’re probably going to be out of luck here.  nVidia cards do have some support for XvMC, but you sacrifice color in your on screen display and it rarely works properly.  Furthermore, XvMC has some architectural issues that cause problems when decoding HD size content frames.  In November, however, nVidia announced the creation of VDPAU - the Video Decoding and Presentation API for Unix.  In a nutshell, VDPAU is a moderately generic API, like Microsoft’s DxVA, that utilizes nVidia’s PureVideo technology to display video with less CPU.  Taking less CPU means that you can do more in the background and not worry about stuttering — or, if you’re concerned about power, heat, and noise, like most MythTV users, you can use a more efficient less power hungry processor.  Just how much better is it?  The guys at Phoronix did a series of VDPAU benchmarks that showed CPU usage with VDPAU go from around 40% with X-Video to less than 5% with VDPAU.  More savings for you.

Even though VDPAU has been released for only a month, the MythTV guys are hard at work supporting it.  The first patches for VDPAU support were committed in late November and there has been heavy development ever since.  If you’re thinking about getting a new video card an nVidia 9000 series looks like it would be a great choice.

The Future

I’ll be honest, there are times that I get really frustrated with the slow progress of MythTV and how the development seems to stall out frequently, despite its fairly large user base.  I don’t consider myself  a developer of MythTV, but I have contributed patches to the project, such as allowing the transcoder to crop letterboxes and pillarboxes from videos, and have worked as an advocate of MythTV locally.  Despite this, the poor usuability of the project continually has me evaluating other options, such as Boxee, which provides integration with Hulu and soon Netflix, but sadly lacks the ability to record and play back television.  I was really excited when Nero announced LiquidTV, but the poor review and complete inability to record QAM make it useless in hilly Pittsburgh where cable is required if you want to receive more than one or two stations.  So, for the time being, I’m on MythTV — it has a suitable wife acceptance factor and allows me to record most everything I want.  The changes coming down the pipe for 0.22 will only make that better.

However, due to the infrastructure of MythTV, it’s not easy to add a new TV listing service. Rather, the change from Zap2it to Schedules Direct required all users to upgrade their copies of MythTV to the newest version of the stable branch. Unfortunately, this version still has issues with transcoding high definition signals. The major issue is that mythtranscode has no knowledge of the program aspect ratio. It ends up storing pixels that aren’t needed, such as what happens when a 16:9 signal is sent in a 4:3 signal (letterboxed) or when a 4:3 signal is sent in a 16:9 signal (pillarboxed, much more common). In an ideal world, MythTV would know how to cope with these automatically when transcoding and just magically cut off the offending portions.

Pillarboxing on an episode of The Simpsons recorded from a high definition source

Letterboxing of a Frontline episode recorded from a standard definition source

While the result is still acceptable, it’s not perfect and may force you to switch aspect ratios to watch the video. About a year ago, I wrote a patch for MythTV that transcoders to specify a target aspect ratio. This was against MythTV 0.20, and because the newer versions didn’t provide that many desirable features, I never updated the patch or my installation of MythTV. Facing the impending loss of guide data just days before that start of the NFL season, and only weeks before the start of the new TV season, I updated the patch for MythTV 0.20.2. You can find the transcoding aspect ratio patch in the MythTV Trac system.

The patch still is far from perfect, and you’ll need some cron hackery to get it to work right. The main reason is because although MythTV allows you to create non-standard transcoder names in the frontend, it won’t let you use them for anything but the default transcoder. To get around this, you’ll need to look into your MythTV database and get the transcoder id numbers. For my system, I created a set of transcoders for 1080i, 720p, and 480i content that give me the option
of whether or not to resize on the transcode and the quality. Run the following command on your database to get a listing of the transcoders:

mysql> select * from recordingprofiles;
+----+-------------------+-------------------------+-------------------------+--------------+
| id | name              | videocodec              | audiocodec              | profilegroup |
+----+-------------------+-------------------------+-------------------------+--------------+
                                          :: snip ::
| 27 | 1080i No Resize   | MPEG-4                  | MP3                     |            6 |
| 28 | 1080i Resize      | MPEG-4                  | MP3                     |            6 |
| 29 | 720p No Resize    | MPEG-4                  | MP3                     |            6 |
| 30 | 480i No Resize    | MPEG-4                  | MP3                     |            6 |
| 31 | 720p Resize       | MPEG-4                  | MP3                     |            6 |
| 32 | 720p Resize Med   | MPEG-4                  | MP3                     |            6 |
| 33 | 1080i Resize Med  | MPEG-4                  | MP3                     |            6 |
                                          :: snip ::
| 46 | 1080i SDTV Resize | MPEG-4                  | MP3                     |            6 |
| 47 | 720p SDTV Resize  | MPEG-4                  | MP3                     |            6 |
+----+-------------------+-------------------------+-------------------------+--------------+
47 rows in set (0.01 sec)

Transcoders 27, 28, 29, 31, 32, and 33 all leave the aspect ratio unchanged. Transcoder 30 is a transcoder that resizes 480i letterboxed content. Transcoders 46 and 47 remove pillarboxes from SDTV signals transmitted over HD. You’ll also notice that I have different transcoders for 1080i and 720p. You don’t need to do this, but I have chosen to do this to avoid deinterlacing 720p signals — saving a bit of time and power.

The final step is to tell MythTV to periodically update the transcoders settings. I use a simple script called from cron about every 15 minutes:

#!/bin/sh
MYTHPASSWORD="-pYOURMYTHPASSWORD"
echo "update recorded set transcoder=28 where chanid=3215 or chanid=3220 or chanid=3212 or chanid=3211;" | nice -n 10 mysql -u mythtv $MYTHPASSWORD mythconverg
echo "update recorded set transcoder=31 where chanid=3213 or chanid=3210 or chanid=3214;" | nice -n 10 mysql -u mythtv $MYTHPASSWORD mythconverg
echo "update recorded set transcoder=47 where (chanid=3213 or chanid=3210) and (title='The Simpsons' or title='Family Guy' or title='American Dad' or title='King of the Hill');" | nice -n 10 mysql -u mythtv $MYTHPASSWORD mythconverg
echo "update recorded set transcoder=47 where (chanid=3214) and (title='Mad Max' or title='Bubble Boy' or title='Hotel Rwanda');" | nice -n 10 mysql -u mythtv $MYTHPASSWORD mythconverg
echo "update recorded set transcoder=47 where (chanid=3210) and (title='The Ten Commandments');" | nice -n 10 mysql -u mythtv $MYTHPASSWORD mythconverg

This script forces the 1080i channels to use transcoder 28 and the 720p channels to use transcoder 31. The last three lines are for pillarboxed programs that recorded off 720p that must be unpillarboxed. With this in the background, when transcoding I select the default transcoder and the output will be properly cropped.

As an added bonus, this patch also fixes issues with mythtranscode not understanding that 1080i signals are encoded as 1088 (due to MPEG files needing to be a multiple of 16 lines high) and encoding a nasty gray bar at the bottom of your 1080i transcoded vidoes. It also cuts off the top eight pixels of most recordings because Comcast normally sends junk on those lines that looks like static.

Update: I didn’t mention on my original post that if you schedule a recording via MythWeb, there is an option to set the transcoder. In this screenshot (click for full size), you can see where I specified the transcoder “720p SDT Resize” for use on “The Simpsons”.

Here’s the dirty little secret you may have not known. Altough the chip you bought may support this wonderful technology, your motherboard may not be able to enable it. I previously had an AMD Athlon 64 3500+ in an MSI K8N Neo4 Platinum motherboard. It was really a nice combination, worked pretty zippy. Then, when Conroe dropped at the end of July, I decided to take advantage of the price drops and install a nice new AMD Athlon 64×2 4400+. After all, it was just a matter of dropping the chip into the board. When I booted up though, I was greated by something I didn’t expect. The new system was drawing 65 watts more power than the old system was. Ouch. A look at the dmesg logs showed exactly what the problem was.

Aug  2 13:06:39 spongebob kernel: [4294696.356000] powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.50.4)
Aug  2 13:06:39 spongebob kernel: [4294696.360000] powernow-k8: BIOS error - no PSB or ACPI _PSS objects

That’s odd, that can’t be normal. I looked back further in my logs and found this result from my Athlon 64 3500+:

Aug  1 07:10:00 spongebob kernel: [4294691.444000] powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.50.4)
Aug  1 07:10:00 spongebob kernel: [4294691.444000] powernow-k8:    0 : fid 0xc (2000 MHz), vid 0x6 (1400 mV)
Aug  1 07:10:00 spongebob kernel: [4294691.444000] powernow-k8:    1 : fid 0xa (1800 MHz), vid 0x8 (1350 mV)
Aug  1 07:10:00 spongebob kernel: [4294691.444000] powernow-k8:    2 : fid 0x2 (1000 MHz), vid 0x12 (1100 mV)

Time for some fun hacking away at stuff. Apparently, this means that my motherboard wasn’t providing the correct data in the BIOS for the operating system to know how to sleep the processor. In other words, while my processor could be put to sleep, the motherboard didn’t know how to. The specific item that Linux was looking for is called the Differentiated System Description Table, or DSDT for short. Lucky for us, there is a feature of Linux that lets you override the motherboard DSDT with one you specify yourself. Wonderfuly, just hack the DSDT and you’ve got powersaving! Wait, you didn’t say we’re going to hack the firmware of a critical system did you? Of course I did! It’s not that hard, so let’s jump right in!

First things you’ll need the Intel ASL compiler/decompiler to build get your DSDT to a readable format. Under ubuntu this is just a matter of running sudo apt-get install iasl. Now we’ll dump the DSDT to a file and then decode it to make it human readable. Linux is nice in that it makes the DSDT availble at /proc/acpi/dsdt

cat /proc/acpi/dsdt > custom.aml
iasl -d custom.aml

This should have created a file called custom.dsl. Open it up with your favorite text editor and have a look around. If you’re like me and lacking support for power saving, see a block for your processors that looks a little like this at the top:

    Scope (\_PR)
    {
        Processor (\_PR.CPU0, 0x00, 0x00000000, 0x00) {}
        Processor (\_PR.CPU1, 0x01, 0x00000000, 0x00) {}
    }

The \_PR scope defines ACPI information for your processors. As you can see here, it’s completely empty. There are a couple of ways to populate it, you can either trust the snippet of code that I’m going to paste below, or you can try to find your own information from the ACPI4Linux DSDT Repository. You’ll need to find a DSDT for a motherboard that is reasonably close to yours, thus if you’ve got a socket 939 motherboard, like I do, you’ll need to find a DSDT for a different socket 939 motherboard. Unfortunately, their site is very difficult to navigate, so if you trust me, you can paste the information here.

Scope (\_PR)
    {
        Processor (\_PR.CPU0, 0x00, 0x00000000, 0x00)
        {
            Name (_PCT, Package (0x02)
            {
                ResourceTemplate ()
                {
                    Register (FFixedHW,
                        0x00,               // Register Bit Width
                        0x00,               // Register Bit Offset
                        0x0000000000000000, // Register Address
                        )
                },

                ResourceTemplate ()
                {
                    Register (FFixedHW,
                        0x00,               // Register Bit Width
                        0x00,               // Register Bit Offset
                        0x0000000000000000, // Register Address
                        )
                }
            })
            Name (_PSS, Package (0x04) // number of p-states
            {
                Package (0x06)
                {
                    0x0898, // 2200 MHz
                    0x000105B8,
                    0x64,
                    0x07,
                    0xE020298E,
                    0x018E
                },

                Package (0x06)
                {
                    0x07D0, // 2000 MHz
                    0xFCBC,
                    0x64,
                    0x07,
                    0xE0202A0C,
                    0x020C
                },

                Package (0x06)
                {
                    0x0708, // 1800 MHz
                    0xD610,
                    0x64,
                    0x07,
                    0xE0202A8A,
                    0x028A
                },

                Package (0x06)
                {
                    0x03E8, // 1000 MHz
                    0x6B6C,
                    0x64,
                    0x07,
                    0xE0202C82,
                    0x0482
                }
            })
            Name (PSXG, Buffer (0x18)
            {
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
            })
            Name (PSXF, Buffer (0x18)
            {
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
            })
            Name (PSXE, Buffer (0x18)
            {
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
            })
            Name (PSXD, Buffer (0x18)
            {
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
            })
            Name (PSXC, Buffer (0x18)
            {
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
            })
            Name (PSXB, Buffer (0x18)
            {
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
            })
            Method (_PPC, 0, NotSerialized)
            {
                Return (Zero)
            }

            Name (PSSC, 0x0A)
        }
        Processor (\_PR.CPU1, 0x01, 0x00000000, 0x00)
        {
            Name (APCT, Package (0x02)
            {
                ResourceTemplate ()
                {
                    Register (FFixedHW,
                        0x00,               // Register Bit Width
                        0x00,               // Register Bit Offset
                        0x0000000000000000, // Register Address
                        )
                },

                ResourceTemplate ()
                {
                    Register (FFixedHW,
                        0x00,               // Register Bit Width
                        0x00,               // Register Bit Offset
                        0x0000000000000000, // Register Address
                        )
                }
            })
            Name (APSS, Package (0x0A)
            {
                Package (0x06)
                {
                    0x09999999,
                    0x00099999,
                    0x00999999,
                    0x00999999,
                    0x99999999,
                    0x99999999
                },

                Package (0x06)
                {
                    0x09999999,
                    0x00099999,
                    0x00999999,
                    0x00999999,
                    0x99999999,
                    0x99999999
                },

                Package (0x06)
                {
                    0x09999999,
                    0x00099999,
                    0x00999999,
                    0x00999999,
                    0x99999999,
                    0x99999999
                },

                Package (0x06)
                {
                    0x09999999,
                    0x00099999,
                    0x00999999,
                    0x00999999,
                    0x99999999,
                    0x99999999
                },

                Package (0x06)
                {
                    0x09999999,
                    0x00099999,
                    0x00999999,
                    0x00999999,
                    0x99999999,
                    0x99999999
                },

                Package (0x06)
                {
                    0x09999999,
                    0x00099999,
                    0x00999999,
                    0x00999999,
                    0x99999999,
                    0x99999999
                },

                Package (0x06)
                {
                    0x09999999,
                    0x00099999,
                    0x00999999,
                    0x00999999,
                    0x99999999,
                    0x99999999
                },

                Package (0x06)
                {
                    0x09999999,
                    0x00099999,
                    0x00999999,
                    0x00999999,
                    0x99999999,
                    0x99999999
                },

                Package (0x06)
                {
                    0x09999999,
                    0x00099999,
                    0x00999999,
                    0x00999999,
                    0x99999999,
                    0x99999999
                },

                Package (0x06)
                {
                    0x09999999,
                    0x00099999,
                    0x00999999,
                    0x00999999,
                    0x99999999,
                    0x99999999
                }
            })
            Method (APPC, 0, NotSerialized)
            {
                Return (Zero)
            }

            Name (PSSC, 0x0A)
        }
    }

Whew, that’s a lot of data. Don’t ask me what it all means either, because I’m not an ACPI expert. I had to dig around to find a DSDT that worked for me. You’ll notice that I have 4 different processor power states, which correspond to the states for the AMD Athlon 64×2 4400+. If your processor doesn’t have four states, such as with an Athlon 64 3500+, then you’ll want to comment out the fastest state and change the line that says number of p-states to 3 instead of 4. Anyway, your mileage may very. You’ll also notice that the first value for each p-state corresponds to the speed in MHz. I’ll leave it as an exercise to the reader what sort of damage you can do with that.

Great, now you’ve got your spiffy new dsl file — time to compile it and have the kernel load it. Running the command iasl -tc custom.dsl will produce a file called custom.hex, this is your new compiled DSDT table for inclusion in the kernel. If you’re like me you might have had errors at this point. If you’re smart, you can fix them, if you’re lazy you can ignore them. I chose the latter.

Because you’re running Ubuntu (right?), the kernel source tree already has support for Cool’n'Quiet by default. But it doesn’t enable drivers that require additional firmware. Unselect Device Drivers-> Generic Driver Options-> Select only drivers that don’t need compile-time external firmware. Then go to Power management options-> ACPI Support -> Include Custom DSDT and give it the path of your custom.hex file you just created. Finally, rebuild your kernel with make-kpkg clean && make –append-to-version=-customdsdt kernel_image modules_image kernel_headers initrd. This will dump a few new .deb files in /usr/src for you. Install them with dpkg -i and reboot!

After the reboot your system will take lots of juice initially, that’s because a system is usually pegged during the boot sequence, but afterwards it should drop precipitously. You can verify it’s working by looking at the contents of your dmesg output and see the following:

[17179571.504000] powernow-k8: Found 2 AMD Athlon 64 / Opteron processors (version 1.50.4)
[17179571.508000] powernow-k8:    0 : fid 0xe (2200 MHz), vid 0x6 (1400 mV)
[17179571.508000] powernow-k8:    1 : fid 0xc (2000 MHz), vid 0x8 (1350 mV)
[17179571.508000] powernow-k8:    2 : fid 0xa (1800 MHz), vid 0xa (1300 mV)
[17179571.508000] powernow-k8:    3 : fid 0x2 (1000 MHz), vid 0x12 (1100 mV)

If you see something like this, congratulations, it’s working quite well. It’s not perfect, I still get a few little error, but at least Cool’n'Quiet works now. My system idle power dropped from 195W to 134W. Going off the rough estimate the 1W of power costs about $1/yr, that’s a saving of $61! Nice. Of course, it took me about four hours to figure this out, which means it may have not been worth it, espeically if I apply a discount rate to my future savings, but I digress. If you use external proprietary drivers, it might be worth your time to install module-assistant so those get compiled too. Otherwise you’ll boot your nice new kernel without support for 3d acceleration and all that jazz.

After all of this, I found a nice package that allows for the placement of the DSDT in the initrd. Using this method, you don’t need to recompile your kernel every time you change your DSDT — instead you just rebuild your initrd. Very nice for situations where the drivers aren’t always built as part of the kernel build process, such as IVTV.

Happy Hacking!

To test each of the machines I hooked them into the Kill A Watt for an extended time period and watched the load of the machine at different times. For multiple tasks on the machines I would read the Watts from the Kill A Watt and then look at the overall power usage over an extended period. For the costs of electricity I used the price on my July 2006 statement from Duquesne Light, which is about $0.10 per KWh. At this rate, 1W on all year costs a little under a dollar.

So let’s start out with dearly departed Scissors. Unfortunately, I did the measurements on scissors a long time ago and since have given it away, so I couldn’t get the same variety of measurements. Scissors was a tiny K6-200 machine with 96MB of ram and a single Quantum Fireball 4.3GB hard disk. It had no other disk drives, furthermore, the fans on the machine were broken. Over a course of 100 hours, this machine consumed about 3.78KWh - an average usage of 38W, for a yearly cost of $32.58.

Next I monitored the power consumption of Igel, my current server machine. This machine is a PIII-900MHz machine with a single 45GB drive, CDRW drive, and 768MB of RAM. As this is a server, I didn’t break the load down by category. Over 1222 hours (yes, that’s well over a month), the machine used 84.4KWh of power, for an average consumption of 69W and a yearly cost of $59.22. The faster machine costs nearly twice as much as the older machine to power.

Next up I did two rounds of measurements on Spongebob, my MythTV box. The first round of tests were done before the upgrade I gave it as a birthday present to myself. At this point, Spongebob was an AMD Athlon 64 3500+ with 3 200GB hard disks, 1G of ram, a WinTV PVR 250, a pcHDTV HD-3000, and a DVD drive. I should also mention that the northbridge fan was not working. Over 96 hours the machine used 10.17KWh of power, for an average of 106W and yearly cost of $90. When watching HDTV the consumption shot up to 130W - increasing the cost to $111. Luckily, it’s not watching HDTV that often.

Recently I upgraded Spongebob to a AMD Athlon 64×2 4400, 1 200GB hard disk, 4×320GB hard disks, 1G of ram, a WinTV PVR 250, 2 pcHDTV HD-3000s, and a DVD drive. I also replaced the northbridge fan with a really fancy lanboy style cooler. Initially, however this new configuration did not support CPU throttling. The load was averaging about 165W making the cost $142.32. Ouch. That had to change. Luckily, there’s a way to fix this that involves hacking your kernel and your ACPI settings, but I’ll cover that later. When monitored over 97 hours the machine consumed 13KWh of power, for an average of 134W and a cost of $114.89. Watching HDTV put the usage back up to 165W, which left the $142.32 cost. Overall, adding in the upgrades costs me about $25/yr in power costs, significant, but still the MythTV box comes out to less than $10/month.

For convenience, here’s a chart showing some of the power costs:

So what’s this going to change? I had no idea that running Igel was costing me $60/yr for just power. Wow. That’s gonna make me do one of two things, either migrate the virtual machines down to the MythTV box, or purchase a cheapo shared server — probably the former. With that sort of change, our power consumption will be under the levels from when I had scissors as my server and the pre-upgraded Spongebob as MythTV (total consumption of 141W) as opposed to 134W now. Still, I’m a little shocked at the power consumption of everything. I wish I had an easier way to quantify the power consumption of individual components of the system. If anyone knows of a way, short of ramming probes into the
system, I’d love to hear it.

However, if you record a lot of stuff, or even a moderate amount of stuff
in HD, this property and increased delay can be quite annoying. It can take several extra hours to cut and
transcode an hour long HDTV program when running at 1.2GHz instead of 2.4GHz (my analysis shows
a greater then 2.5x slowdown - which is weird in itself). First, let’s cover the reason
you system slow down, and then we’ll cover what to do about it.

Processors take a lot of power - most of that power is dissipated as heat
because of the resistance in the CPU. Slowly, AMD and Intel are realizing that people
don’t want extra heaters in their living room/office, that powering all of these computers puts a real dent in your wallet, and that most of the energy is wasted because the processor is idle anyway. The solution? Create not only more effecient processors,
but also allow processors that throttle back to conserve power when they’re not being fully
utilized. On the Athlon 64 platform this is called
“Cool’n'Quiet”
and has been available since the Winchester core chips.

Cool’n'Quiet works with a couple of different parts: a Cool’n'Quiet enabled
processor, a Cool’n'Quiet enabled motherboard, and a software program that
manages it all. If you’re running a socket 939 Athlon 64, you’ve almost
certainly got the first two. Under Linux, you can directly control the CPU
power state through the proc file system, or you can have a
daemon process, such as powernowd, manage it for you. Ubuntu installs powernowd automatically and starts it for you, so out of the box you’re getting
some of the benefits of this technology.

However, powernowd is configured to not take into
account nice processes. Normally, this is fine, nice processes can afford to
run a bit slower, that’s why they’re nice in the first place. Unfortunately,
it is only set up to consider nice processes as a group and can’t differentiate between a process that can’t take advantage of increase speed and one that can, such as transcoding. And, as you’ve probably guessed
by now, to minimize interference with other programs, MythTV runs transcoding and commercial flagging processes as nice.
To speed them up all we need to do is tell powernowd
to take into account nice processes.

In Ubuntu, this is really straight forward. Most startup scripts for daemons
look in the /etc/default directory for local
configuration overrides. By default powernow is
run with only the -q flag, telling it to be quiet.
If we also pass the -n flag, it will take nice
processes into account when deciding whether or not to throttle the processor.
The solution, create a file /etc/default/powernowd
with a single line in it:

OPTIONS="-q -n"

Then issue the command /etc/init.d/powernowd restart
and your computer will no longer throttle itself when transcoding and commercial
flagging. Enjoy the increased speed of transcoding and happy MythTVing.

After three weeks of fighting, vengeance will be mine. I’m returning the board and getting a new ASRock 939Dual-SATA2 board instead. This requires me to pick up a firewire card too and means that all the slots will be filled up from the get go. But whatever, we’ll see how this works. I may have to do another return if that doesn’t work well.

For those that are concerned, I’ll eventually put up a TRAC site for managing the project and
and providing access to the repository of revisions. My goal is to provide a slightly more up-to-date
and Ubuntu centric version of Jarod
Wilson’s Fedora MythTV Guide. I know, that’s a lot of hoping. Come on magic
google juice, lead people to me.

So what’s a guy to do then? I bought a system to make it HDTV compatible, but the HDTV is sucking it up. I can get HDTV over the firewire, so I may just have to loose digital cable for right now. Maybe this is the kick in the ass that I needed to create the mutually exclusive tuners. Here’s a brief explanation of what this would do.

Normally, I’ve got my WinTV PVR-250 hooked up to the cable box via svideo, and the channels are changed through firewire. This lets me record all the channels out of the cable box in analog mode. This card is also hooked up to the standard cable input and can tune the lower channels just fine. In addition, I’m able to pull the firewire HDTV signal from the box onto my computer. However, as you can now see, when I pull in the firewire HDTV signal, I’m going to end up changing channels on the WinTV PVR-250 that is getting it’s signal over firewire. So, I’d like to make it so only one of either the WinTV PVR-250 (with SVideo) and the Firewire cable input can be used at the same time. Furthermore, it would be neat if as an extension, when the Firewire input was in use, it would automatically let my WinTV PVR-250 know that it should use the standard cable tuner input. I wonder how hard this would be to hack together.