One of the first things I learned [the hard way] when I
started writing software was the real difference between the public API
(objects, methods and functions documented in the SDK), private API (undocumented
but accessible objects, methods, and functions) and implementation
details. Of the three, only the public
API is guaranteed. It is a contract
between the developer and the platform, like all contracts there are some grey
areas, things that are open to interpretation or purposely left vague to allow
some wiggle room as the platform expands, but the promise is still valid. The platform and its support structure stands
behind the public API, if it breaks - it
gets fixed.
Of course in the real world it's often difficult to meet
requirements using only the public API so you cheat a little, peak under the
covers (dumpbin, reflector, hex editor, etc) take on the risk that what your
application is using isn't documented or supported. Trusting that changing the private API or
implementation is costly enough to the platform that it won't happen that
often. Sure it's annoying when that stuff changes but you have no right to
complain when it does.
So what does all that mean for DVRMSToolbox (DTB) and the TV
Pack? Some changes were necessary to
make WTV work properly inside the application.
Most of DTB uses DirectShow to interact with the files so that aspect of
the transition was relatively painless.
Some things, like the metadata parser, are based on implementation
(DVR-MS is ASF), so branching was necessary (DirectShow for WTV, ASFParser for
DVR-MS) but for the most part everything in DTB that runs outside of Media
Center that worked with DVR-MS should work with WTV. There is one major exception, the RecComp
object (edits DVR-MS files) does not work on WTV. Not a huge issue, as we've already discussed
how to convert/change the file format into something that can be edited (and
there is an update to ToDVRMS that supports WTV).
Other applications that provided native DVR-MS support (SA,
Comskip, Mencoder, etc) will need time to provide the same kind of support for
WTV that we enjoyed with DVR-MS. These
tools are all based on implementation so this outcome was not unexpected, even
if MS provided container documentation (which
they haven't, and may not) it would take a while for tool support to catch up. I'm confident that over time these tools will
get modified to provide the same level of support. If you were one of the original DTB users,
you'll remember that there was a time when DVR-MS had to be converted to mpeg
for commercial scanning so this is nothing new.
The story inside Media Center is different however. Anyone who's installed the TV Pack and DTB should
already know that automatic commercial skipping inside Media Center doesn't
work. While there are aspects of the DTB
Addin that rely on unsupported features, the part that does the skipping isn't
one of them.
When a recorded TV file is played back the addin receives a
notification from MSAS to start monitoring the position within the file and
checking that position against the known list of commercials. These public API objects uses to determine
playback state and position (MediaExperience and therefore its child objects)
are not populated (null) during playback, a state that should never occur. This
is a blocking bug in the public API. I have examined other approaches to making the addin work
during playback, but because of the breadth of this issue it would be very
difficult to make anything work that would be anything close to stable. At this time I do not plan to pursue a
technical solution further.
Personally I find it appalling that the pack would ship with
a bug of this magnitude. Either testing
was so cursory that it wasn't discovered, or it was a known issue and the
decision was made to ship anyway. It's
hard to say which is worse.
Microsoft has confirmed that the issue exists, but they do
not plan to develop a QFE or even publicly document it via a KB article. At this point the only option that I have
been provided is to write a business impact statement in the hope that the
effected population is big enough for MS to care about. DTB doesn't have any kind of tracking
mechanisms to determine install base so determining the effected pool will be
difficult. If you are a TV Pack and
DTB user let me know. Hopefully there
will be enough of you to get noticed.
UPDATE - 9/4/08:
While I classified this as a rant (because some parts of it are), please understand that I want to get this fixed and I need your help to do that (if you work at, or run, a major OEM even better).
As Charlie mentioned below, trashing MS isn't helpful and more importantly this isn't the forum to do that (that's what TGB is for ;)); if you are effected let me know with a comment or an email (avantil at gmail period com); and since not every TV Pack user reads my blog get the word out (thanks to all those who have).
Also, I should have made it clearer that while I don't agree with MS' process for getting a QFE(business impact and all that); I understand why that is their process and playing by their rules is the only way this is going to get fixed.