Archive for the ‘DVR’ Category

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.

No switching between analog and digital audio output on the nForce3

Saturday, November 25th, 2006

The audio output on my MythTV system is connected to a reasonably nice stereo, and it feeds the stereo both analog and digital audio, depending on whether you tell it to use ALSA:mixed-analog or ALSA:mixed digital as the playback audio device. I frequently switch between the two. HD broadcasts use digital sound, as do DVDs, but due to a quirk in the wiring, I need to use analog sound if I want to route the sound to my television and use TV volume controls.

I’m not the first person to have this problem, so I was hopeful when I found an article about switching the playback source with a remote control button in the MythTV wiki. In that article, there’s a script that uses the amixer command to switch the “IEC958 Playback Source”

#!/bin/sh

# Get current setting of PCM/analog switch
AUDIO=`amixer get ‘IEC958 Playback Source’ | grep ‘Item0:’ | cut -d\’ -f 2`

if [ “${AUDIO}” == “PCM” ]; then
# Route analog signal to S/PDIF
amixer set ‘IEC958 Playback Source’,0 ‘Analog’
# Could also be: sudo /sbin/alsactl -f /home/mythtv/asound.analog2spdif restore 0
else
# Route PCM signal to S/PDIF
amixer set ‘IEC958 Playback Source’,0 ‘PCM’
# Could also be: sudo /sbin/alsactl -f /home/mythtv/asound.pcm2spdif restore 0
fi

Excited, I opened a command line to see if I had support for selecting the audio source, but found that my nForce3 doesn’t support it:

myth ~ # amixer | grep IEC958
Simple mixer control ‘IEC958’,0
Simple mixer control ‘IEC958 Playback AC97-SPSA’,0

Nuts! I’ve filed this mentally under the reasons why I want to do a hardware re-spin on my Myth sytem. Although all of the parts were reasonable selections at the time, I would like to replace the noisy 60 mm fans in the Silverstone case (and maybe get a few more drive bays while I’m at it), and get a bit more processing power for transcoding.

Upgrading to MythTV 0.20

Saturday, November 25th, 2006

I have now finally upgraded to MythTV 0.20. The big reason for my delay is that the upgrade presented itself as a bit of a big project, largely because the Gentoo package system told me that an X Window System upgrade was required. I have been happily running xorg 6.8 for a year and a half, but Portage told me that I’d need to upgrade to xorg 7.1. At first glance, the report of what needs to be upgraded is massive, since the X package is now modular instead of monolithic. I was quite busy, so I didn’t want to upgrade such a critical system component without the time to fix it if it went wrong. As it turns out, my fears were misplaced, and the upgrade went off without a hitch in about an hour.

Unlike my previous upgrade to 0.19, the upgrade to 0.20 is an unqualified success. The highlights are:

  • KQED audio is back! There is something strange about the digital broadcast from KQED (the biggest PBS station in the San Francisco area). I’ve had recurring problems with getting the audio to work right in Myth. First, it was the lone holdout in Transport Stream/Program Stream conversions in 0.18. After I upgraded to 0.19, I was missing audio on KQED-HD (channel 9.1) but not on any of their secondary standard-definition channels (9.2, 9.3, 9.4, and 9.5). In 0.20, audio is available on all of the channels without any issues. In previous versions, I would have to periodically scan through the list of recordings and delete recordings that came out on the HD channel so they would be picked up on the secondary channels so that I would have sound.
  • XvMC seems to work flawlessly. I’ve also had recurring problems with XvMC on my AMD64. I don’t need XvMC to play back HD, though it seems silly to me to spin up the chip to its fastest speed when it’s not necessary. Much of the random behavior I saw previously seems to have been fixed. I don’t know if this is MythTV, the nVidia drivers, or the X server, but I’m quite pleased.
  • There are now several options for the On-Screen Display (OSD). I’m partial to the “Gray-OSD” which has a sort of transparent effect.
  • MythDVD’s internal player is now the default that I’m using. In 0.19, I was still using Xine because the internal player didn’t support DVD menus. The internal player now supports DVD menus, and that was enough to push me over the edge. The internal player uses the same keymap, which makes programming the remote control easier. Plus, the keystrokes are the same as for MythTV, which means that it’s easier for me as a user. Most importantly, the internal player has a rewind function, but Xine does not. (Xine does have a rewind function in the GUI, but it doesn’t expose it to the keyboard as far as I can tell.)
  • I haven’t used it yet, but the new MythArchive plugin should make it easier to burn DVDs of recorded shows, which will be easier for me than dumping everything to videotape.

My only complaint right now is that I can’t get the icon display in the on-screen display to work, but that should be easy to fix with a little bit of digging.

Zap2it program guide data for MythTV goes AWOL for San Francisco broadcast TV

Thursday, November 23rd, 2006

This week, my MythTV system stopped recording on most of the over-the-air digital channels. I had noticed, for example, that a program was supposed to record on Sunday, but did not, even though it had appeared in the to-do list on Thursday. This seemed quite strange, until I looked at the program guide data and found that only two of the channels were receiving program guide data:

No guide data!

I tried to refresh the database contents using mythfilldatabase, but the program completed quickly and didn’t put any data in. A check of the MythTV mailing list turned up the suggestion to add the XMLTV channel id numbers, but I added those numbers to my system when I first built in in 2005. To try and figure out if the problem was my system or the data feed, I ran mythfilldatabase in verbose mode, and found that it wasn’t receiving any data for most of the channels. A check from Zap2it Labs showed that the number of available channels was very small because most of the digital channels didn’t exist. Of the channels I received, only KTSF-DT and KCSM-DT (2 subchannels) were feeding me guide data.

Missing channels at the data feed

The eventual work-around was to delete my over-the-air channel lineup and re-create it from scratch. As part of that process, I received a much fuller list of channels to pick from for some reason:

Zap2it Labs rebuild, now with all channels back

With all the right channels selected, I could run mythfilldatabase to get all the data for the next two weeks, minus the current day. (To get the current day, you need to run mythfilldatabase –refresh-today.)

It appears that what happened is that at some point last week, Zap2it rebuilt their channel lineup. Every day, mythfilldatabase dutifully went out to get new data, and received an indication from Zap2it that the channel had no programs. Therefore, all the scheduled recordings would show up until the day before they would normally be expected, at which point, they guide data would get clobbered and they would drop off. Thankfully, everything seems to be running fine now.

Jeers! to TiVo for taking three years to figure out WPA

Tuesday, November 21st, 2006

This afternoon, I received the latest TiVo newsletter. My TiVo and I have been drifting apart for years, in large part because TiVo seems to be falling behind. Today’s newsletter bragged about how the current TiVo software update now has WPA:

MORE SECURITY: Choose either WEP or WPA security for your wireless networks (WPA requires the TiVo Wireless Network Adapter) [Networking nerds cheer.]

Actually, we don’t cheer you. We wonder what took you so long.

A serious network engineer would never use WEP, because it is unsafe at any key length, and we’ve known that for more than six years. WPA was announced on October 31, 2002. (I remember that date because I was speaking on wireless security the day after the announcement, and the audience asked about it.) WPA-certified products have been available since 2003.

In 2003, my home wireless LAN was running WPA. When I discovered that my TiVo could only support WEP, I grudgingly pulled an Ethernet cable into the living room because I didn’t feel the need to downgrade my network security to WEP.

In September 2004, I was invited to be part of a security panel at the Wi-Fi Security Seminar in Washington, D.C. Before the panel took the stage, I vividly remember talking with David Cohen of Broadcom, who was leading the marketing efforts for the Wi-Fi Alliance on WPA2. In our discussion, David pointed out that many consumer electronics devices were supporting WPA, and that there was no reason why anybody needed to use WEP. When I pointed out to him that TiVos only supported WEP and that they had no apparent plan to support WPA, he was shocked. I never imagined that the situation would remain unchanged for the next two years.

To add insult to injury, the upgrade doesn’t help the TiVo customers who are already using 802.11. TiVo WPA support doesn’t work with just any wireless adapter like the one that most users already have stuck into the USB port. Oh no, it requires the use of the TiVo-branded wireless adapter! The TiVo adapter lists for $60, which is a pretty high price premium over a “standard” USB-to-802.11 network adapter. With careful shopping, you can get a regular Linksys/D-Link/Netgear adapter for $20 or less.