Archive for December, 2006

Setting up an APC UPS on Linux with apcupsd

Sunday, December 31st, 2006

In the time that I’ve been living in my current home, there have been a couple of power interruptions, but nothing that was more than a blip until the past week. For quite some time, I’ve used an APC SmartUPS as a line conditioner to feed power to my network gear. It wasn’t until I experienced an outage that would have outlasted the batteries that I turned to making the device work as a trigger to shut down the network.

Most of the shut-down is conceptually simple. All of the network equipment (firewall, AP, switch, hubs, DSL modem, ATAs) is solid-state and can be powered down abruptly. The main piece of equipment that I need to take some care on is the Asterisk server. Fortunately, there’s apcupsd, a software package that will speak to the APC in it’s so-called smart mode. When the power goes out and the battery drains to a pre-set level, apcupsd can initiate a system shutdown.

Most APC devices these days interface with the computer over USB, though a somewhat strange protocol. To speak it, you need to enable USB support in Linux for Human Interface Devices (HIDs), but with a special “hidden” mode (the CONFIG_USB_HIDDEV kernel option).

As a basic first step for USB support, you’ll need to build support for your host controller. Most controllers these days follow the Open Host Controller Interface (OHCI), though a Intel and Via chips use the alternative Universal Host Controller Interface (UHCI) instead. To find out which one you have, probe your PCI bus to see the controller. It will helpfully tell you which one to use:

root@ups:~ # lspci -v | grep USB
00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (prog-if 10 [OHCI])
00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (prog-if 10 [OHCI])
00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller (prog-if 20 [EHCI])

The final controller is the Extended Host Controller Interface (EHCI), better known as a USB 2.0 controller. UPSes don’t operate at high speeds, so all you need are the host controller and the human interface drivers:

root@ups:~# modprobe ohci-hcd
root@ups:~# modprobe usbhid

Now, plug in the UPS. If your distribution is set up right, the udev system will create the /dev/usb/hiddevX device interface to talk to the UPS. You can see it by looking at the kernel messages:

usb 2-2: new low speed USB device using ohci_hcd and address 2
hiddev96: USB HID v1.10 Device [American Power Conversion Smart-UPS 750 XL FW:630.3.D USB FW:1.4] on usb-0000:00:13.1-2

At this point, I could follow the standard gentoo path of emerge apcupsd and do the basic configuration. The halt scripts on Gentoo are even configured to automatically turn off the UPS after shutdown, so I didn’t have to do anything special to power down my rack once the shutdown completed.

MicroATX boards for a MythTV HTPC

Friday, December 29th, 2006

When the power failed Wednesday, the house was quiet because I had to power down all my electronica. Individually, each piece is quiet, but added together, there’s a definite background noise. As I powered up each computer individually, it was easy to see what contribution it made to the overall noise level.

It turns out that my MythTV system is louder than I thought. The main problem is the 60 mm case fans, even though I have them undervolted. As part of a home-theater redesign, I’ve been thinking of re-spinning the hardware on the MythTV system to make it smaller, so I might as well try to quiet it further as well.

I’ve learned a couple of lessons on the case. Lesson One is that a full-size ATX case is big. The Silverstone is nice-looking, but it’s still big. It’s too deep for most home theater furniture, and it’s easily the biggest piece of equipment that I need to work with. Lesson Two is that the acoustics of the case aren’t that great, and that 60 mm fans should be banished from any HTPC case. (I purchased the case in early 2005, and 60 mm fans were hard to avoid then.)

I’ve been impressed with the reviews of the Antec NSK 2400 case, which isn’t surprising. Mike Chin of Silent PC Review was a consultant on the design. He recently worked with EndPCNoise.com to design off-the-shelf systems, and the SPCR-designed HTPC uses the NSK. I will probably go with the Antec Fusion, which has a VFD and covered drive bay, but is otherwise the same case.

The downside of using the NSK is that I’ll need to totally re-spin the hardware, since the NSK is designed for MicroATX motherboards. To pick out a new motherboard, I started with a wishlist:

  • Video chipset. mATX motherboards usually have limited slots, so I would like built-in graphics. I’ll be running MythTV, so nVidia is preferable because their drivers are more Linux-friendly than ATI. However, the chipset isn’t everything, because I have concerns about the…
  • video connector. I do not want to take up a slot to get the right output form factor. Ideally, the board would have a standard-definition output (either composite or S-Video), and forward-compatible HD output. HDTVs all seem to want HDMI, but it is possible to buy a HDMI-to-DVI cable, since the electrical signaling is the same between the two. If HDMI or DVI is unavailable, then component outputs are acceptable.
  • Optical audio output (S/PDIF), to transport the 5.1 digital sound broadcast with HD 5.1 to my receiver. One cable is easier than six, and I already have the digital audio cable run in my current cabinet. In a pinch, I might be willing to settle for six analog outputs and a cable control solution, but that would be ugly.
  • Southbridge. I’m not real picky on this chip, but there is one feature I’d like. It’s apparently possible to watch sports without listening to inane announcers by muting the center channel audio in a 5.1 broadcast. My receiver has the tools for doing this, but there may be some support required in the audio chipset.

I am staying agnostic on the CPU. In the past, AMD motherboards have been much cheaper, especially when you pair them with a low-power CPU. Intel has generally discouraged use of the ultra-low power Pentium M in a non-laptop setting, and the high prices of Pentium M-compatible motherboards reflect that. If I were to stay AMD, I would prefer to stay with the old socket 939 form factor because I could re-use my existing CPU, but that’s not really important.

My usual procedure is to head over to newegg.com and fire up their search engine to sort through the huge universe of motherboards. (They don’t carry AOpen motherboards any more, though.) In the Intel world, there is only one Socket479 mATX motherboard, the Asus N4L-VM DH, which doesn’t have DVI output.

As I expected, the AMD world has more choices, but all of them have a minor annoyance:

  • Asus M2NPV-VM. This is the motherboard used in the EndPCNoise Model Eleven designed in conjunction with SilentPCReview. The annoyance is that the on-board audio controller doesn’t have digital outputs. To add digital outputs, I would need to buy an add on PCI Express card because both PCI slots will be occupied by tuners. (Come on, Asus! Does this board really need a parallel port? Take that off and replace it with a S/PDIF optical port.)
  • Abit NF-M2. Abit has had some quality problems in the past, which is a small downside to this board. It’s almost completely “legacy-free.” Not only are there no parallel or serial ports, but the board doesn’t even have headers for them. I would need to buy a new remote control sensor to work with USB, instead of using my existing serial port remote sensor. My main problem with this board is one of backwards-compatibility, though. Right now, I am still using a standard definition TV, and the video solution on this board lacks a standard-definition output. Interestingly, this board has two S/PDIF ports, though I can’t see using the input port any time in the near future.
  • DFI Infinity C51PV-M2/G. This board has everything on my list, with the possible exception of the hard-to-verify audio switchability. However, it’s not really a mATX board. The maximum size of a mATX board is specified as 244 mm x 244 mm (roughly 9.6 inches square), and this board measures out at 244 x 264 mm. On one side, it’s 2 cm too long (or almost an inch). I am not sure if this would be a problem in the Antec case, and I’m not going to order it and find out.

One other notable mention is the DFI RS482 Infinity. Unlike the previously mentioned DFI board, it is 244 mm x 244 mm, and would fit in a mATX case without difficulty. SilentPCReview has praised its undervoltability and power saving capabilities. However, it is based on an ATI graphics chipset, which seems like a pretty big risk to take with MythTV.

The Power Company (PG&E, in this case) cares about your alarm clock?

Wednesday, December 27th, 2006

I started off my day at home today, but there was a big windstorm that knocked out power for 50,000 customers this morning. When I called PG&E to report it, they offered to let me set up a wake-up call using an automated system. I must admit that it was quite a surprise to hear about that extra level of service. Generally, I do not expect utilities to provide for needs above and beyond the basic service that they provide.

(The conspiratorial part of me wonders why the power company has rolled out this service. Did they get sued by some employer who claimed that no wake-up alarms made a large number of their employees late and therefore, the suit sought to recover loss due to late employees?)

My UPS worked fine, though I don’t have enough run time to do much except go to my rack and power everything down. I should figure out how to get it to trigger a network shutdown so that everything doesn’t go down hard in case I’m not at home.

Cisco 7912 ignores DNS servers in DHCP assignments?

Saturday, December 23rd, 2006

My initial experiments with VoIP were all behind my firewall. Now that I want to have Asterisk interact with the rest of the world, I need to follow the Interop Labs 2006 advice and keep NAT away from VoIP because they don’t mix. I’m redesigning the integration of VoIP into my home network. I’ve moved my Asterisk server on to a DMZ where it now has a routable IP address.

One of my VoIP devices is a Cisco 7912 IP phone. Even if I’m willing to put a fortified (and firewalled) server outside the firewall, I still plan to keep VoIP devices inside. To make the phone aware of the new server address, I went into the phone configuration and changed the SIP server from its old IP address inside the firewall to a DNS name outside the firewall. When the phone restarted, it stubbornly refused to register. By looking at SIP debugging on Asterisk and firewall logs, I could tell that the phone was not sending the initial SIP registration message to the server. Moreover, I could tell it wasn’t even trying to look up the name I had entered for the SIP server. When I replaced the name with the IP address stored in DNS, everything worked just fine. Fortunately, I don’t plan to be changing my server’s address any time soon, so I can live with this small annoyance.

Reverse commuting and BART parking

Saturday, December 23rd, 2006

I’ve just started reading The Capricious Commuter, a blog about transportation in the Bay Area. When I was going through the archives, this statement jumped out at me:

I know this, because I’ve trolled the lot at Pleasant Hill after 9:15 a.m. looking for spaces. It took 20 minutes and made me feel stupid for imagining that someone might be leaving at that time of the morning.

I don’t know much about parking dynamics at Pleasant Hill. Earlier this year, arriving at about 9 am was a perfectly valid strategy for the Pleasanton station. Before the parking fees at BART, I used to drive to BART in the evening to get home. I’d get a good spot near the entrance to the station, and take the train home. On the next morning, I’d take the train back to my car and drive the short distance to work. Between 9 and 9:30 every morning, there were usually 10-15 people who would do the same, and it was common for a few cars to be waiting at the end of the first row of parking spaces to take advantage of the spaces vacated in the morning.

Now that there’s a parking fee, there are no spots vacated early in the morning. My guess is that those riders have started driving to Pleasanton, bought reserved permits, or started using the bus. Back when the parking fees were being studied, I wrote to my BART director to ask him to allow the “reverse commute” overnight parking, but obviously my letter wasn’t something he paid attention to.

MythDVD 0.20 is cool

Tuesday, December 12th, 2006

One of the pleasant surprises in the MythTV 0.20 upgrade was the improved functionality in MythDVD. In 0.18 and 0.19, I had an unattractive choice. I could use either xine, which supported DVD menus but didn’t rewind, or MPlayer, which supported rewind but not the the DVD menus. (Xine does have a rewind button in its skin, but there doesn’t appear to be a keyboard shortcut for it, which makes it impossible to use with LIRC.)

The MythDVD 0.20 internal player supports DVD menus, so there’s no reason to use an external player. The internal player supports everything that TV playback does, so I get a unified GUI, plus I can use the same keys to adjust aspect ratio, audio tracks, and captioning.

The key point of a DVD player on Linux, though, is to ignore the forced commercials at the start of the disk. In Xine, I defined a special key just to jump to the root menu. To do the same in the internal MythDVD player, I decided to overload the keystroke that I’ve assigned to CH_PREV, which means my “previous channel” button is now the time-saving jump-to-the-root-menu button.

What time is it? Or, starting recording on time with MythTV

Tuesday, December 12th, 2006

In the past couple of weeks, I’ve noticed that the programs that I’m recording on MythTV are missing the first few seconds to a minute of programs on the major networks. At first, I thought that maybe this was due to a clock problem on the MythTV system, so I checked the NTP synchronization. Everything looked good there. ntpd had switched away from my ISP’s server, probably because it is only stratum 3, and the public servers in the NTP pool are stratum 2. However, the time received from all four NTP servers was within a 45 millisecond gap, so apparently, my time was good. (For extra assurance, I used ntpdate against one of the NIST servers, and it came back with an adjustment of less than two milliseconds.)

Next, I checked the MythTV system against my TiVo. They appeared to have nearly identical time. That’s not particularly surprising. Years ago when I was troubleshooting a problem, I noticed on a network trace that the first task a TiVo performs when connecting to the service is to do a time update with NTP.

However, I noticed that my VCR, which receives a time signal from PBS, was three minutes faster than MythTV and TiVo. I’m not sure how PBS sets its time signal, but it seems weird that it’s three minutes off of the official time.

I’m not sure what I’ll do now. The active approach is to set Myth to start recording every program a minute early, but I’d have to go and change the configuration of every recording manually (or figure out how they are stored in the database). The passive approach is to hope that this is a transient problem that will correct itself if I leave it alone.

Anybody else experiencing this problem? If so, what did you do about it?

Recording HDTV with MythTV

Saturday, December 2nd, 2006

In a comment to the upgrade post, a reader comments:

How are you recording HD channels with Myth? Last time I checked, all the available HD tuners out there (ATI, Hauppauge, etc) only record over-the-air broadcasts.

I’m in Canada and I get my HD via a cable box, but I can’t seem to find a reasonable solution to record it with Myth. Component-video (Y Pb Pr) capture card? Too expensive. Over the air? Too unreliable. Firewire output from cable box? Not available through Rogers. Cablecard? Not supported by Rogers either.

This is a thorny enough topic that I wanted to call it out in a full post, rather than let my answer get buried in the comments.

To answer the first question: I am recording over the air (OTA). OTA recording gives you access to the full-rate video stream, whereas cable/satellite providers will often squeeze the stream into a smaller size to fit more of them into the transmission pipe. This may manifest itself in areas of “flat” color or pixellation. (When I last went to a video store to look at large high-definition sets, they had all of their 50″ and up TVs tuned to a satellite HD feed, which looked pretty bad because it was so compressed. If I were selling TVs, I’d want to have a system that showed off the full-rate picture at its best, but I digress.)

I’m fortunate to be less than three miles from San Francisco’s TV transmitter, which does make my life a bit easier. (You might be surprised at how difficult it can my life, too, since some of the channels I receive come in too strong for tuners to lock up.) I’m using two different HD tuners: the pcHDTV HD-3000 and the AirStar HD-5000. My MythTV system has three tuners because I like to be able to pad recordings out by a couple of minutes, so it’s not uncommon for me to have all three tuners going at once.

Unfortunately, this means that reliability isn’t really that big a concern for me. I have had to set up my antenna very precisely, but if I were willing to get on my roof, I think that would be less of a concern.

CableCARD. I’m not all that familiar with CableCARD, but it is not consumer friendly. According to Dave Zatz, the cable companies are the reason why there is no Tivo-to-Go on the Series 3. Microsoft did strike a deal to get Cable Labs certification for Media Center PCs, but that’s only likely to help large Media Center PC suppliers, not MythTV do-it-yourselfers.

Component capture. I don’t know of any consumer-level device for this. Over-the-air broadcasts run within the 19.2 megabit/s (2.4 megabyte/s) broadcast limit. Uncompressed, the stream takes a significantly higher amount of capacity. I did some back-of-the envelope calcuations on the stream capacity, and I came up with the following nubmers. (Note that these are all based on 60 fields per second, which is the North American standard, and that there will be additional overhead to store the container for the data frame.)

Standard Resolution bits/pixel megabytes/sec
720p 1280×720 8
10
52.7
65.9
1080i 1920×1080 8
10
59.3
74.2
1080p 1920×1080 8
10
118.7
148.3

I don’t know of any consumer-level storage solution that can write 50-150 megabytes per second. Maybe there is somebody working on a component-capture card that can do the MPEG-2 encoding, but I don’t know of one. MPEG is asymmetric, so encoding takes a quite bit more processing punch than decoding.

(This doesn’t even get into the DRM surrounding HD component capture, wherein some high-def devices may not supply you full resolution without implementation of a protection scheme.)

Unfortunately, there is no good answer to this question. Over-the-air broadcasts are the only way to efficiently get HD into MythTV. The EFF is on the case, though that is probably cold comfort to people outside the U.S. living with legal “innovations” like the DMCA.

Another lineup rebuild erases MythTV guide data

Friday, December 1st, 2006

When I arrived home tonight, I checked on my MythTV system to ensure that it was going to record tonight’s programming, and once again, I saw that it was going to sit idle this evening. In the car on the way home, I’d heard an ad for a new episode of 30 Rock, so I thought that couldn’t possibly be right.

A quick check of the guide data showed that there was “NO DATA” on TV, just like last week. Only now, it was because the format of the digital channels stored by Zap2It apparently changed. When I went to edit the linup on line, I saw that the digital channels had vanished; re-constructing the lineup showed the problem. The digital channels are now referred to not by their frequency, but by their remapped number. (In the picture below, KQED’s digital channels are 9-1 through 9-5; a week ago, they all appeared as channel 30.)

New format for digital channels

While the data feed has changed, I am not comfortable with MythTV’s blind acceptance of it. If the new data update causes all the guide data to be erased, it seems like a useful safety feature to retain the old data and raise an error message. Part of the reason I use MythTV is that I have a 3-tuner setup, so had I not caught this problem, I would have lost some of what I intended to record tonight. Instead, I would prefer that MythTV retain guide data if it does not receive an update.