16.7ms in the life : Media Center

Media Center Technical Discussion 1: Tuners and TuningSpaces

Peter Rosser — Tue, 04 Apr 2006 06:08:00 GMT

The Media Center TV experience driven by a flexible, multi-standard engine that works with any compatible tuner (including a good number of analog tuner cards and all BDA digital tuner cards) to create portable recordings viewable on any Windows XP machine. To support “trick play” on Live TV (Pause, FFWD, etc.), the video engine is separated into two main segments: capture and playback. The capture engine, controlled through the Media Center Receiver Service (ehrecvr.exe), is responsible for creating the actual recordings, including controlling tuners, creating a media stream, and optionally encrypting the stream before writing it to disk. The playback engine, controlled through the Media Center Shell (ehshell.exe), processes media streams created by the capture engine and renders them for the user. Everything else, as far as TV goes, is built on top of or leverages these two components.

The capture engine uses the Microsoft Unified Tuning Model, with TuningSpaces and TuneRequests, as a layer on top of the physical tuner, allowing Media Center to treat tuners agnostically. To actually tune to a channel, Media Center first creates (or looks up) a tune request that corresponds to that channel, then submits it to the capture engine, which uses it to tell the tuner what to do.

A TuningSpace corresponds to code written specifically to handle a type of video broadcast, such as ATSC, NTSC, or DVB-T. Some properties are present in all TuningSpaces, like its ID (e.g. {8A674B4D-1F63-11D3-B64C-00C04F79498E} for NTSC Analog Cable), and some are specific to an implementation. The implementation-specific properties--like NetworkType or DefaultLocator for digital standards--let the capture engine configure the underlying BDA driver, and provide a way to tweak default values. A TuningSpace can be considered a "template" for how Media Center will try to talk to the tuner card, depending on how you have it configured--mapping roughly to the old TV setting of "Antenna" or "Cable".

All by itself, a TuningSpace is not enough to actually tune to a broadcast stream. For that, Media Center creates a TuneRequest (by using the ITuningSpace object). A TuneRequest can be thought of as "everything you need to know about tuning to a channel"; what it contains varies from TuningSpace to TuningSpace. For an NTSC tune request, you could expect it to contain a channel number and a reference to the TuningSpace; an ATSC tune request would contain a physical channel (the "major" channel) and a minor channel; a DVB-T tune request would contain the broadcast frequency, ONID, TSID, and SID. All tune requests contain a reference back to the proper TuningSpace.

Media Center stores information about which TuningSpace(s) are configured on the system on a per-tuner basis in the Windows registry under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Service\Video\Tuners key. If you open this key, you'll see something like this:

The GUIDs correspond to "tuning categories", which are digital ({71985F48-1CA1-11D3-9CC8-00C04F7971E0}) and analog ({A799A800-A46D-11D0-A18C-00A02401DCD4}), each containing subkeys that correspond to individual tuner devices. Note that there can be more than one tuner device per physical tuner card or USB device--Media Center treats multi-tuner cards as separate devices. I will use my Hauppauge WinTV PVR PCI II device's entry as an example:

As you can see above, the tuner's auto-generated GUID is {99F4E181-4B58-4258-8547-2CE73F3C0386}. This key is created by the ehrecvr service automatically when it detects the tuner: for a PCI card, this happens at service startup; for a USB device, this happens either at service startup or when you plug in the device. If you delete the key and restart the ehrecvr service--and the card is still installed--a key will be created with a new GUID. If a USB device is detached and reattached to a different port it will also get a new key.

Examining the properties, there are a couple of interesting values:

ConfiguredTuningspace is a REG_MULTI_SZ that contains a list of the TuningSpace IDs for which this card has been configured in Media Center.
SupportedTuningspace contains a list of the TuningSpace IDs with which the tuner's driver reports compatibility. These lists can differ if the tuner supports more than one type of tuning, like some of the newer "hybrid" tuners--a card that supports both NTSC and PAL is an example of such a card.
DevInstance, DevName, and DevPath are obtained from the tuner driver, and give Media Center "pointers" to the physical device. If you open up Device Manager and look at the advanced properties for the matching device, you will find that the values map 1:1 to entries here.
PrefEncoder either points to another hardware ID (in the case of a tuner with hardware MPEG2 encoding) or a software encoder (e.g. ATI AIW cards). This is populated after we successfully build a capture graph for the device, and points to the MPEG2 encoder that is included in the graph at that time.

It's important to note that ehrecvr will create a key for every tuner device detected, whether or not it is configured in Media Center or not. Whether it is available for tuning in Media Center is just a matter of whether the registry keys says it is. For example, you can easily get more than 2 tuners working for scheduling, recording and Live TV viewing by editing the registry entries for the tuners to enable them. The reason that you cannot do this through the UI is simply because there is not a good graphical way to resolve recording/viewing conflicts amongst more than 2 tuners for a given TuningSpace. Instead of being able to choose which of the 4 tuners to "steal", you can only choose from 2 of them. However, with 4 tuners you're much less likely to actually need conflict resolution, so IMHO it's acceptable.

To actually get the n-tuner scenario working properly, every tuner must be in the same TuningSpace, and change channels the same way. So you cannot mix STB with non-STB, Satellite with Cable, etc. This is due to limitations in the Guide and PVR engine, not in the capture or playback engines. STB tuners are somewhat of a pain, so I recommend using Method 2 (below) if you are going to go with n-tuners on STBs. Also, you must have an STB for each and every tuner... not a fun scenario if you have to pay for each one.

This week's Media Center tweak is getting N tuners working in Media Center. There are various versions floating around out there on the internet, most of which include extra, unnecessary steps, likely because the authors figured out this stuff without the benefit of internal knowledge of the codebase, so they included everything they did to get it all working. The version of this tweak posted on The Green Button works just like Method 2 below, but requires a reboot between each configuration run.

If you have NTSC + ATSC, you can use this method for the ATSC tuners, the NTSC tuners, or both! The only limitations are your hard drive's bandwidth, your system bus bandwidth, CPU time, and the number of tuners you can attach to the machine. For NTSC that means a practical limit of about 10 tuners, if they are all recording non-DRM content. For High Definition ATSC and DVB it's a little more intensive, but since there's no encoding going on (digital broadcasts are already encoded!), it actually balances out a little, with a top limit of around 7-8 tuners. I have personally run 3 ATSC + 6 NTSC on my home system (through dual-tuner USB devices like the Adaptec AVC-3610), and it hummed right along (1 GB DDR Dual-Channel DDR 3200 RAM, Pentium 4 2.8 GHz (HT), 2x 7200 RPM 500GB Hitachi SATA drives in RAID-0 with the system/boot drive on a 40 GB PATA drive). That's a bit more than I need, so I backed off to only 3 NTSC (2 USB + 1 PCI) and 2 ATSC (both PCI).

Step-by-step, here's how to get n-tuner going. Both methods assume you've already installed the tuners and have the drivers installed.

N Tuners in MCE, Method 1 (only registry editing):

Stop the Media Center Receiver Service (net stop ehrecvr)
Open Registry Editor (regedit.exe) and open this key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Service\Video\Tuners\{GUID}
where {GUID} is either {71985F48-1CA1-11D3-9CC8-00C04F7971E0} for Digital (ATSC or DVB-T) or {A799A800-A46D-11D0-A18C-00A02401DCD4} for Analog (NTSC or PAL).
Under the {GUID} key, there will be one key per tuner device.
Select the first tuner's key.
Select the UserSettings key.
Set these DWORD values as follows (case sensitive, all values in hexadecimal), creating them if they do not exist:
EnabledForMCE = 0xffffffff
UseSTB = 0
Create a REG_SZ value named UserDefName and set its value to "Tuner X", where X is the tuner number (1 for the first tuner, 2 for the 2nd, etc.)
If this is the FIRST tuner:
RecordOrder = 0
RecordPrefered = 0xffffffff
WatchOrder = number of tuners - 1, e.g. for 4 tuners set this to 3
WatchPrefered = 0

If this is the LAST tuner:
RecordOrder = number of tuners - 1, e.g. for 4 tuners set this to 3
RecordPrefered = 0
WatchOrder = 0
WatchPrefered = 0xffffffff

If this is a tuner somewhere in the middle:
RecordOrder = whatever you put for the last tuner + 1
RecordPrefered = 0
WatchOrder = whatever you put for the last tuner - 1
WatchPrefered = 0

The idea here is that you increment the RecordOrder by 1 for each tuner, and decrement the WatchOrder by 1. RecordOrder starts at 0 on the first tuner and goes up to #Tuners - 1; WatchOrder starts at #Tuners - 1 and ends at 0 on the last tuner. RecordPrefered is true (0xffffffff) on the first tuner, false (0x00000000) everywhere else; WatchPrefered is true on the last tuner, false everywhere else.
Repeat steps 7 - 10 for each tuner, adjusting the values of RecordOrder, RecordPrefered, WatchOrder and WatchPrefered as appropriate.
Close Registry Editor.
Start Media Center. Voila!

Yes, "Prefered" is misspelled. We caught that after we shipped, and it's a little late to change now...

N Tuners in MCE Method 2 (a little registry stuff, no manual editing though):

Start the Media Center shell (Green Button)
Go to Settings-->TV-->Set Up TV Signal
Choose the 2 tuners from the list of tuners that you will configure this time (first time through, just the first 2)
Close the Media Center shell.
Stop the Media Center Receiver service (net stop ehrecvr or stop the service from Control Panel-->Administrative Tools-->Services)
Open Registry Editor (regedit.exe) and open this key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Service\Video\Tuners\{GUID}
where {GUID} is either {71985F48-1CA1-11D3-9CC8-00C04F7971E0} for Digital (ATSC or DVB-T) or {A799A800-A46D-11D0-A18C-00A02401DCD4} for Analog (NTSC or PAL).
Under the {GUID} key, there will be one key per tuner device.
Find the 2 keys that were just configured by Media Center. You can tell which ones they are by looking for the "EnabledForMCE" value under the UserSettings key. If it is set to 0xffffffff, it was configured--otherwise it will be 0x00000000 (0).
Export the 2 keys to .reg files on your hard disk. (right-click on the {GUID} key and choose Export [selected branch only]). Make a note of where you save those files... you're going to need them! Name each one differently (e.g. Tuner1.reg, Tuner2.reg).
Repeat steps 1 - 8 for each set of 2 tuners (if you have 3, then just then 3rd, etc.), selecting different tuners each time.
Repeat steps 4 and 5.
Double-click on each of the .reg files you created in step 9 to import them into the registry.
Close Registry Editor.
Start Media Center. Voila!

Next week we'll talk about the PVR engine and recording management.

This posting is provided AS-IS with no warranties. The views expressed above do not represent those of Microsoft Corporation.

Media Center Technical Discussion Series

Peter Rosser — Mon, 03 Apr 2006 21:52:00 GMT

One of the more popular subjects for users who email me is how to get Media Center to do something that cannot be done (or is hard to do) from the UI. Since I have not been able to talk about my current work much (Windows Vista and unannounced other stuff) I am kicking off a roughly weekly technical discussion on tweaking Media Center.

Planned discussions:

Tuners and Tuning Spaces
PVR and Recording
Unattended/Scripted Configuration
Video Playback
Writing Your Own Media Center Application

Want to know how to tweak something in Media Center that's not listed above? Let me know and I'll see if I can work it in.

VoodooPC's 8TB Media Center PC

Peter Rosser — Fri, 03 Mar 2006 01:51:00 GMT

From Engadget:

When we heard that VoodooPC was planning a media PC with 16 drive bays and a maximum capacity of 8 terabytes... [Read full posting on Engadget]

Sounds pretty cool--maybe I'll get one here to "test" with ^_^.

DVB Guide issues - "cannot schedule recoding because guide data cannot be accessed"

Peter Rosser — Thu, 16 Feb 2006 10:27:00 GMT

We have been getting reports about Guide problems from DVB users across Europe and the world, hopefully in time for the next Rollup release (external date not yet announced, but should be late Q1 to early Q2). The problem typically manifests itself when scheduling many shows to record, but can occur anytime. Without a code fix, you cannot work around the issue cleanly/easily, but closing the shell (Media Center UI) and restarting the "Media Center Scheduler Service" (ehsched) will reset the state of the machine.

Edit: This is the "cannot schedule recording because guide data can't be accessed" issue.

We root-caused the problem to an unusual memory management problem in how we deal with the Guide data. For performance reasons, we temporarily increase certain buffer sizes during a Guide download, and decrease them again later. There is a timing issue with garbage collection events in some situations, though, that can cause the decrease to not take effect "in time", thus keeping the buffer sizes large. This does not actually reduce the amount of real memory used, but it does exhaust the virtual address space eventually. You can observe the behavior using SysInternals' Process Explorer by adding the "Virtual Size" column (under the Process Performance tab) and observing its value for ehrec.exe.

With better knowledge of the cause, though, comes a better workaround than "gun ehshell.exe and restart ehsched when it happens". Until the fix comes out, the best thing to do to prevent this problem from occurring is probably to set up a Scheduled Task to do those things for you at a predictable time. To wit:

Download recycle_mce.cmd from here. (script to recycle ehshell.exe and TV services). Unpack the script somewhere on your drive.
Change your Guide download time to a time that you are not likely to have a need to either watch TV on your MCE or record a show. 4am is pretty safe for me, but to each his own. I wrote a tool that lets you edit this time easily, you can download it from my site.
Create a Scheduled Task to run the script daily about 30 minutes after the time you configured the Guide to download. If you have a modem, you may need to give it more time. If you have a pretty fast computer and broadband, 30 minutes is very generous. Guide to creating scheduled tasks.

It's not a perfect solution, since a) it presumes you have a time during the day you will not make recordings or watch TV, and b) it cannot prevent the problem 100%, especially if you are a "heavy" user. If you run into the problem, though, running recycle_mce.cmd will at least reset your state.

The real fix is coming with the next rollup, but since there are users out there feeling pain now, I thought I'd try to help a little.

The programs, scripts, and instructions in this posting are provided AS-IS, with no warranties, and are not sanctioned nor released by Microsoft.

A Brief History of ATSC in Media Center

Peter Rosser — Fri, 03 Feb 2006 11:09:00 GMT

In the beginning there was NTSC in Freestyle (Media Center 2002), and it was good. Media Center supported the #1 market and proved that computers could do a great job recording television, pausing Live TV, and organizing recordings. With support for one tuner under our belt and an enthusiastic user base, we moved forward with Harmony (Media Center 2004) to a more mature, flexible and polished product that supported dual NTSC or PAL tuners, opening up the European, Asian and Australian marketplaces. A few intrepid souls figured out how to hack together ATSC support into Harmony using little-known interfaces and scarce hardware like the VBox 110.

Between the release of Harmony and Symphony (Media Center 2005), ATSC demand increased by leaps and bounds, though still smaller than the NTSC base by far. To this day, only a very small percentage of Media Center users actually use ATSC, although it's a matter of some discussion whether that number is small because the number of HDTVs is small, or because Media Center's support is... less than optimal. In any case, by the release of Symphony the user community was clamoring for ATSC support without hacks, and was disappointed when Symphony shipped without it. An update quickly followed, though, and Symphony Rollup 1 with HDTV Support was released as a free update through Windows Update and the Microsoft Download Center. The changes in Emerald (Rollup 2) and Diamond (Windows Vista) did/will not not substantively change the architecture of ATSC, so what we have today will more or less be the way it works for another couple of years.

••• design decisions

When we (speaking in generalities here, since I was not a member of the team at the time) first investigated how to include ATSC into the product, there were several major hurdles standing in the way. The first was a consequence of our decision to use the VMR (Video Mixing Renderer) instead of the deprecated Overlay Mixer for rendering video. Overlay rendering differs from mixing in the way that video is prepared for display. In overlay mode, the video is literally painted over the top of whatever else is being rendered. In mixing mode, "surfaces" with video or other graphics are blended together, either in software or hardware-accelerated, prior to rendering on the monitor. The advantage of mixing mode is greatly increased flexibility in what you can display at the cost of performance. It takes a lot more horsepower to process all those pixels, especially with alpha (transparency) and 3D effects. 99% of the video hardware on the market today uses a form of overlay mode, which drastically reduces the hardware requirements (e.g. no 3D hardware required), but hamstrings them when viewed side-by-side with the sort of effects you can get with mixing. The semi-transparent menus on top of video that you see in Media Center that give it such a cool look are just not possible with overlay mode. All that alpha blending and those 3D effects come at a hefty cost, though. Media Center has to work many times harder to get the video to the screen, even when no special effects are on-screen at the time. That, in a nutshell, is why Media Center requires not just an OK video card to shine. And a faster CPU. As a result of the increased power needed to render video, and with the hardware available to consumers in 2000-2002, it wasn't really feasible to offer HD with the first couple of releases.

Even if the video could keep up (which it could on higher-end systems, even in 2002), there was another difficulty: Guide data. The problem is that when you get multiple lineups (the term we use for the programming information associated with the set of channels available on a given medium in a geographical area), merging them into a single lineup and making it easy for the user is not an easy solution. The decision was made to punt it until demand was increased, and to stick with a simpler homogenous lineup, rather than the more advanced heterogeneous lineup that would be required to support both NTSC and ATSC on a single system. The market of people that have more than one TV provider is, after all, not that large, and we wanted to get it right for the most people we could.

••• support for ATSC gathers steam

A vocal minority of the user community, along with a large majority of the eHome TV product team, were not pleased with the lack of support. We got the funding to put ATSC in the product, as long as we could fit it into the schedule and without major risks to the architecture of Media Center's TV and PVR functionality. With compressed schedules the norm, and the development and testing staff already deeply into a bad work/life balance, many options were considered for getting ATSC out to users. What was finally implemented is a good first stab at doing it, with a few facets that are, um, less than what we'd like them to be. Since we did not have ATSC-specific listings available through our Guide data provider for many, many areas, we looked instead at reusing the data available from existing analog lineups via "mapping". Since ATSC channels are in a completely different format (like 13-1 or 9-5), and to avoid putting a new button on the remote (requiring a redesign), ATSC channels are renumbered in the UI. The scheduling/PVR conflicts were just ignored, leaving it up to the user to say "only record this channel", omitting support like "record this in HD if you can, but get it in SD if not". The end result was a pseudo-heterogeneous lineup support that we have today. You do get the additional ATSC lineup merged into your Guide, but the analog source is still required--you cannot have ATSC without NTSC today.

••• the current state of things

During First Run (the initial Media Center setup wizard), or TV Signal Setup, we detect whether you are in a region that supports ATSC, and then detect if you have a compatible ATSC card installed (or for Emerald, up to 2 ATSC cards). After configuring your SD tuner, ATSC is configured as an adjunct to the "primary" analog tuners. If you choose an analog, sans-STB (set-top box) cable lineup for your analog tuners, then that data is what's available to ATSC to map to its channels. The same goes for satellite or OTA (off-the-air/broadcast) lineups. Only with digital cable lineups do you usually get the full Guide data to assign to your ATSC channels.

To assign listings to the ATSC channels in the lineup, we run a heuristic match against the available channel metadata, and try to get a "best-fit" match for existing channels to the new ATSC channels. For example, if there is a channel "KOMO-DT" in the primary lineup, it can be matched to the known ATSC channel KOMO-DT on 4-1. In some areas, the match can't be made automatically, but you can go to the Guide settings (Settings-->TV-->Guide-->Edit Digital TV Listings) and manually associate the listings of an existing channel to the ATSC channel. Basically what you are doing is saying "this channel that exists on my "primary" lineup has identical programming to that ATSC channel". It works best with digital cable lineups because they carry all of the local OTA ATSC channels on their networks (due to Federal must-carry laws). To get the minor channels (where the "minor channel" > 1, e.g. KCTS-DT2 on 9-2 in Seattle), you have to add them to your lineup manually using Add Missing Channels, and then map them to listings using Edit Digital TV Listings.

The end result of all of this is a unified lineup that can be presented to the user in a single Guide grid. ATSC channels are assigned numbers like 1041 for channel 4-1, and slotted in where they fit best. If your primary lineup already has a channel 1041, we look for another block of numbers to put the ATSC channels. A side-effect of this is that if your primary lineup is changed--like if Comcast decides to add a channel 1000 to their lineup--the ATSC channel numbers may get reassigned to another empty block. Personally, I'd like to implement a better solution, but as I've said before, we Americans are unnaturally attached to our channel numbers. Most would just give you a blank look if you suggested that we don't even really need channel numbers at all. Not when you have a good enough search/filter mechanism, anyhow.

••• the days to come

For the Diamond release, we have announced support for OCUR (OpenCable Unidirectional Receiver) tuners, which will allow native tuning of digital cable signals, with CableCard support (for premium channels like HBO). This includes HDTV signals, which should be good news to most users. More people pay for TV service now than don't, and if you own a Media Center, you are about 20 times more likely to have cable or satellite service than not. Roughly. OCUR support probably means (definitely, for Diamond) that we won't be supporting heterogeneous lineups anytime soon, which is a shame, but hard to make a business case against. Why spend time and treasure on something that most people won't use, and could possibly destabilize the entire product? That's a little hyperbolic, but the onus is on the people who want the feature to justify it.

We announced a deal with DirecTV where we will directly support their newest STB in Media Center, just like--or very similar to--the OCUR does with digital cable. The field is finally opening up and we're getting to a point where we can offer our users very attractive options for "traditional" TV services. The European market, or more precisely, the non-U.S./S.Korea/Japan market, has already standardized (for the most part) on a fairly sensible broadcasting standard--DVB--which we are improving our support for with every release.

Non-traditional video services are also booming in popularity, with Online Spotlight partners offering more movies and other multimedia content for free (in many cases) or on an ala-carte basis, directly competing with PPV services offered by traditional TV providers. Apple has changed course on its "we'll never get into the PVR business" policy with iTunes video (and their toe-dip product Front Row, which is a pretty spiffy little QuickTime automation script), and The Market is scrambling all over itself to get on the bandwagon. Internet TV is coming, just as soon as we (as in "we the market", not necessarily "we at Microsoft") figure out what Internet TV is.

Fix for ATSC after uninstalling Rollup 2

Peter Rosser — Tue, 24 Jan 2006 22:24:00 GMT

In some cases you may find that ATSC (HDTV) no longer works after uninstalling Media Center Rollup 2 from your computer. The issue is caused by a schema change in the Tuners registry key. Today I identified a workaround to get your ATSC back up and running without reinstalling Symphony or Rollup 2.

To restore your ATSC functionality in Symphony:

Stop all Media Center services and processes

Close Media Center
Start-->Run-->services.msc (or Control Panel-->Administrative Tools-->Services)
Stop "Media Center Receiver Service"
Stop "Media Center Scheduler Service"

Open Registry Editor (Start-->Run-->regedit.exe)
Delete the key at:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Service\Video\Tuners
Start Media Center

This has not been rigorously tested, and has not been "officially" released to the Microsoft Knowledge Base yet. I am fairly confident of the fix, but this is posted AS-IS, with no warranties.

DVB Radio "No TV Signal" Workaround

Peter Rosser — Mon, 23 Jan 2006 07:50:00 GMT

I am currently investigating a fix for two DVB Radio issues identified a workaround for those affected. If you are getting a "No TV Signal" blue overlay when tuning to a DVB Radio station, particularly a low-bitrate station like BBC World Service, or you are seeing 15+ second channel change times for changing between DVB Radio and DVB Video channels, this workaround may apply to you.

This involves editing your registry, so if you are not comfortable doing that, please wait for the binary fix to be released.

The key is:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Media Center\Service\Video\Tuners\DVR

Set NearUnderflowCheckMillis=4000 (0x00000fa0).

If you are not experiencing problems with DVB Radio, do not change this value. If you are in the U.S., for example, it can cause instability with ATSC tuning. Once the binary fix is released, you should return this value to its original value of 2000 (decimal).

This is a non-supported, non-official workaround and is provided AS-IS, with no warranty.

Recording over 1394 (Firewire) in Media Center

Peter Rosser — Wed, 26 Oct 2005 09:26:00 GMT

There has been some recent effort to pry open the 1394 interface in various STBs (set-top boxes), most notably that of timmmoore's STB package that goes to extraordinary lengths to hook into Media Center's experience. The state of the world today, at least with Media Center, is that the "outside looking in" hooks of Tim's package are the only way to get that HD content off of digital cable and into Media Center.

Here's how his package works, in a nutshell. You install a couple of drivers that provide a software interface to the various commands you might expect to be available from an STB: channel changing, power toggle, etc. An application then runs in the notification area, or tray, and acts as an intermediary between Media Center and the STB drivers. When Media Center says "Change channel to 54", MyTray (Tim's tray application) listens in via a "hook" into Media Center and sends the channel-change command to the STB. When Media Center starts a recording, another hook lets MyTray know that's happened and MyTray sends a "start streaming video over 1394" command to the STB. When Media Center stops the recording, a similar event happens.

Physically, you connect your computer with the STB by plugging in a IEEE.1394 (Firewire) cable into each. If you have two STBs, you can daisy-chain them together. The traditional "IR" blaster for each STB is removed from the receiver so that it does not interfere with the commands sent over the 1394 connection.

There are a couple of significant downsides to doing it this way:

It's a lot harder to hook in from outside Media Center and try to figure out when channels are changing, recordings are starting or stopping, and in multi-tuner scenarios, which tuner/STB to use than it would be if Media Center could just treat the STB as a virtual tuner.
You still need an analog tuner for each STB you need to control. This may seem odd, but it's part of the reason this works. From Media Center's point of reference, it is still managing all of the recording and channel changing. The fact that the actual channel change is triggered by another application is unknown and unknowable within Media Center.
Since Media Center is still recording over the analog tuners, you end up with two copies of the same program. MyTray can be set to clean up the Media Center version once it knows its recording completed successfully (e.g. no 5C protection from the STB prevented the recording), but you still churn the disk more (2x more for non-HD shows).
Premium content like HBO is likely protected by the STB by the 5C standard, which MyTray does not support. Nor can it without obtaining a 5C certificate, which are pretty hard to get. The sticky parts for most interested parties are the unlimited liability clause you have to sign, and the certification process itself, which I hear is stringent.
MyTray is the product of a single developer, and one person alone cannot bring to bear the necessary development, testing, and packaging resources that bring a high polish to a product. A common saying that applies here is "90% of the work is in the last 10% of the project". Tim did a great job and some impressive detective work getting the app where it is, but getting that "shipping product" quality is a hard job to do all by yourself, working in your spare time.

I am personally using this at home right now, despite the downsides. The fact that I am willing to do this probably means I'm not alone, and in the few informal hallway conversations I've had about it there's a lot of interest in getting this sort of thing done natively in Media Center. There's not matching excitement about funding the cost of doing it, but there seldom is, when it comes down to it.

As Media Center becomes the default SKU for OEMs shipping Windows and our user base grows, there is a tremendous downward pressure on the unit cost of the machines. The first target for downsizing seems to be the tuners, since a fair number of those new Media Centers are being sold as "Tuner Ready" instead of "Tuners Inside". In my humble opinion, implementing a 1394 recording solution is the single best way to get broad market appeal while keeping hardware costs low. Everybody wins: we sell our Windows licenses, OEMs move more units, customers get reliable, scalable SD & HD recording, and the cable companies get their $10 a month from renting their STBs.

Consumers are used to paying the fee, and I think they would continue to do so. There's been a market for leasing otherwise expensive equipment for many years, and there's no reason to think that will change soon. When faced with a decision between $10 a month (or $20 for two STBs), or buying a $250 tuner (or two), a lot of people go for the monthly fee. After all, it takes over 2 years to amortize that, and with technology that seems like a good bet to me. Being on the bleeding edge is more comfortable if you can stay there on a lease. ^_^

Which brings me to the true point of my post: I want to hear how much this feature is wanted in the user community. Is it only wanted by the technically savvy, or do "average" users want it? I really want it, and I don't want this relegated to the "power user" or "enthusiast" bin, because that will result in, at most, a power toy implementation. If we can bring a full feature team to bear on this, I bet we could really make our users happy.

Just think, you could have everything Media Center gives you, plus VOD support (including Pay-Per-View, integrated into Media Center), and HDTV over digital cable. If I'm not mistaken, this could easily expand into satellite STBs, too, if they don't already support streaming over 1394.

I'm going to get back to tinkering with the Network Provider and 1394 tuner classdriver code some more... I'm all worked up with excitement now. ^_^

The procedure entry point GetRequestedRuntimeVersion could not be located in the dynamic link library mscoree.dll

Peter Rosser — Tue, 25 Oct 2005 07:08:00 GMT

Symptoms

Aaron Stebner blogged this a few days ago, but some folks are still running into it, so I'll speak to it a bit. If you get an error dialog with the message "The procedure entry point GetRequestedRuntimeVersion could not be located in the dynamic link library mscoree.dll" during Media Center updates or while running MceRepair, you have (most likely) gotten a corrupt .NET Framework 1.1 installation.

Solution

The fix is to reinstall the Framework from: http://www.microsoft.com/downloads/details.aspx?FamilyId=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en

Root Cause

The most likely cause for this issue is a "clean" reinstall of Windows into the same directory without formatting the disk first. Since the .NET Framework 1.0 is included with Windows XP Media Center Edition, the 1.0 version of mscoree.dll is saved into the Windows directory, overwriting any version (e.g. the 1.1 version) already there. Since the Windows registry is stored in a file that is not completely overwritten during the install, most of the v1.1 entries are left behind, making the .NET Framework v1.1 almost work. Compounding the problem, there are reports that v1.1 is not offered on Windows Update, because the update logic looks for the registry entries that tell it whether it's installed already, and gets fooled.

MceRepair 0.2

Peter Rosser — Sat, 22 Oct 2005 08:20:00 GMT

I've posted an update to MceRepair at http://www.pegasi.com/MceRepair_0.2.zip, which adds additional error logging in case of problems. If you tried 0.1 and it failed, 0.2 may work for you. If not, at least you will have more complete information with which I can debug it. [;)]

DRM Business Rules in Rollup 2

Peter Rosser — Sat, 22 Oct 2005 01:47:00 GMT

To clarify the somewhat vague statement I made about "business rules" for DRM changing in Emerald (Rollup 2), the changes were to include the new COPP (Certified Output Protection Protocol) support in the release and to support the new version of the DRM engine. The actual behavioral changes in Media Center are not that great: we included the new "CopyNoMore" setting (previously "Reserved" in the CGMS-A standard) in our matrix of when to apply COPP, and were the "ship vehicle" for the new version of DRM from the DRM team.

Whether we even engage DRM at all is governed by those "business rules" I was talking about; it's a matrix that defines which protection level we apply to the recorded content based on multiple input vectors. The entire response matrix is quite large, and defines things like whether you can create a recording¹, whether DRM encryption is applied², whether we permit recording the content to portable media, and whether to allow presenting the video over an given output³. In a nutshell, DRM protection/encryption is only triggered in existing analog scenarios when the input content is protected by a) CGMS-A, b) PAL's Copy Protection Flag, or c) Macrovision. Realistically, you're only going to see Macrovision if you are doing pass-through from a VCR or DVD player, or you live in Korea and get your TV from a certain satellite service.

I've only personally seen CGMS-A broadcast on HBO & Cinemax, Showtime, and other "premium" channels. VOD channels are usually marked CopyNever, while scheduled premium channels generally have CopyOnce tags. I hear via forum postings that some people are seeing Fox News' "The O'Reilly Factor" getting marked as Copy Protected in Media Center, but I haven't witnessed it myself. There's certainly nothing stopping broadcasters from setting the 2-bit attribute in their VBI data.

¹ - true for everything but CopyNever content
² - true for everything but CopyFree (or no CGMS-A at all) and no Macrovision
³ - governed by COPP

DRM in MCE Rollup 2

Peter Rosser — Fri, 21 Oct 2005 05:33:00 GMT

I was posting to TheGreenButton.com and thought I'd save myself typing the same thing again, since it's good info, even if I am restating/repackaging existing opinion. The following is a response to people who thought for some reason that Rollup 2 was applying DRM to things that it did not before:

Rollup 2 did not substansively change the way that we determine whether something should be copy protected or not; what it did was change some of the infrastructure of the underlying protection scheme. Basically we revved the DRM version and refined some of the business rules that determine what level of DRM a piece of content gets.

Whether something is protected by DRM depends on whether the broadcaster sends us CGMS/A (Copy Generation Management System / Analog) flags on Line21 of the analog signal. This is *not* the (in)famous "broadcast flag". If you want to know more about how CGMS/A works, there is plenty of material on the net. Another factor is Macrovision (software and/or hardware), or in Europe, the CP flag.

CGMS/A can set 4 different modes: CopyFreely (i.e. no protection), CopyOnce, CopyNoMore (i.e. it used to be CopyOnce, but you made a copy... so you don't get to copy it again), and CopyNever (no copies at all). Since our whole business is built around timeshifting content, we don't count the one stored version as a copy at all, though in CopyNever circumstances the license is generally good for only a limited time.

I'm not a big fan of DRM, but I do see the business need for it. Microsoft makes a big, inviting target for lawsuits if we even appear to be soft on protecting copy protected content. That doesn't make me happy, since it attempts to restrict what I can do with "my" content, and no matter how much I am told (and cerebrally understand) that it's not mine at all, but I'm just licensed to view it, I still persist in thinking of it as "mine". After all, I paid for it! As a consumer, I want complete freedom in what I do with my content. As a stockholder in Microsoft, I want to both protect from lawsuits and grow the consumer market, which seem to be opposing goals.

So what we have is a compromise: DRM. We have encryption technology strong enough to make it not worth cracking (by the time you have cracked it, you've spent more than it would have cost to just go out and buy another copy of the content... probably many hundred/thousand/million times). With the technology also comes the ability for us to open up windows to use the content in limited ways... hopefully the ways that consumers really want to use it. Of course, you can't just send copies around to everyone. But you CAN (or should, if it's working right) put the content on a portable device. Or make a DVD backup.

There's more to this than most people realize, though. Not only do companies like Microsoft and Apple have to guard against lawsuits, etc., but they have to make the studios and other content producers happy enough with the DRM solutions that they will go *farther* and give us more content in more flexible ways. Do you think that Comcast, DirecTV or EchoStar would agree to attach a digital tuner to a PC that can decode their signal without an ironclad guarantee that the content would not just end up on the net? They are terrified of that prospect... and with (arguably) good reason. DRM is what we need to open up PC-based solutions for all of our content. I don't want to pirate my Comcast Digital Cable feed... but I *do* want to watch it! In high-definition and on my Media Center. If the DRM gets out of my way, and lets me burn a DVD for my collection (hard drives are finite, after all), then I'm game. I don't care if I can't just post a video of some HBO movie on the internet. I don't really have the inclination anyhow.

I know there are a lot of folks out there who vociferously oppose DRM on principal. The "information should be free" crowd argues on the principal that you cannot own information, and content is just information. That isn't reality, though, and the courts and laws agree that people who create content can sell it. I won't pontificate further on that, but leave with a parting piece of information relating to the prior paragraph: if the "no DRM" crowd wins, we won't have lots of content with no DRM suddenly... what we'll have is broadcasters and content creators that won't have any reason to share their content. Hollywood will release it's next generation of DVD replacements, this time with something less laughable than CSS protection, and that'll be it. No PC viewing of digital content, just analog. Depressing to me...

</soapbox>

This is just my opinion... I'm not a policy setter, and not on any DRM or Copy Protection team. Fill in all the other disclaimers about my opinion not being my employer's, and all that. ;)

MceRepair 0.1 (alpha)

Peter Rosser — Thu, 20 Oct 2005 10:51:00 GMT

Having gotten a little fed up with manually re-registering MCE files when MedCtrRO.exe fails, I have created a new command-line utility to automate the task.

MceRepair.exe will:

Repair the ACLs to get COM+ Services working again (see KB909444)
Repair the registration for .NET Framework v1.1 libraries (should fix the "Entry Point Not Found in mscoree.dll" error during registration).
Reinstalls all MCE Windows Services
Re-registers COM components of MCE
Reinstalls managed assemblies into the GAC
Recreates native images for managed assemblies (ngen)

Of course, I can't warranty any of this stuff, but if you find it useful, feel free to use it. If you run this and still cannot get things working on your machine, please let me know! Please include your %windir%\MedCtrOC.log file, %windir%\ehome\ehshell.crash (if it exists), and if you're experiencing EPG problems, a zipped/RARed copy of your %ALLUSERSPROFILE%\Application Data\Microsoft\eHome\EPG folder.

MceRepair 0.1 (alpha) is posted at http://www.pegasi.com/MceRepair_0.1.zip [obsolete, use 0.2 below]

EDIT: A newer version, 0.2, is now available at http://www.pegasi.com/MceRepair_0.2.zip

Dealing with the COM+ Patch

Peter Rosser — Wed, 19 Oct 2005 01:39:00 GMT

Last week the COM+ folks released a critical update that has some unfortunate side-effects for people who have tinkered with the ACLs (security permissions) on their drives. Since Microsoft has been beating the security drum for several years now, the number of users who have tightened down the screws wrt their ACLs is probably quite large.

The COM+ update, and the attendant KB articles explaining the problems that can be caused, are very generic, though, so if you are impacted by this problem it's a little harder to link it up with the update. Basically you'll get a lot of spurious error messages in the event log about "inconsistent internal state" and "0x80070005" (which maps to a CRC error according to winerror.exe).

Who does this affect? Only the people running COM+. Who's that? Anyone running Media Center, for example. If you have this problem, the fix is noted on the KB909444 page; basically you have to grant Full Access permissions to System and Administrators to %windir%\Registration, and Traverse Folder (List Folder Contents) permissions to Everyone for %systemdrive%, and %windir% (including subdirs).

Update Rollup KB908250 for Update Rollup 2 for Windows XP Media Center Edition 2005

Peter Rosser — Tue, 18 Oct 2005 21:26:00 GMT

We finally shipped the Rollup QFE, which fixes some ugly issues with Rollup 2, especially in countries with DVB-T service. If you're using DVB-T and Media Center, you really want this update.

If you have DVB-T service and got the "scrambled guide" bug manifesting on your machine before you could install this QFE, what you need to fix it is to reset your EPG data. The easiest way to do that is to go into Settings-->TV-->Scan for more services, click the Delete Existing Services button, and then scan. If you live in an area that can receive more than one DVB-T service that broadcasts the same program, you may still see "duplicates" in your lineup, but that's to be expected.

Even if you haven't experienced the scrambling bug, you should at the very least scan for more services, because we added a bit more flexibility into the scanning code to recognize transport streams with corrupt, missing or downright lying to us NITs (Network Information Tables). If you live in Italy or Spain, in particular, you should get the update and rescan.