Re: HDHomeRun firmware downgrades

[ddl@danlan.*com (Dan Lanciani)]

In article <ErydneBO3ewEZGHbnZ2dnUVZ_g6dnZ2d@xxxxxxx>, ROBERT_GREEN1963@xxxxxxxxx (Robert Green) writes:
| "Dan Lanciani" <ddl@danlan.*com> wrote in message
| news:1341989@xxxxxxxxxxxxxxxxxxxxxx

| > You can read the thread here:
| >
| > http://www.silicondust.com/forum/viewtopic.php?t=4223
|
| At least Nick has promised to help you should their promise of the new FW
| not breaking anything turn out to be more hope than fact.

Yes, unfortunately, based on past experience I suspect the nature of his
help would be to admonish me to use the "supported" software rather than
my own.  Back when I first bought the HDHRs and had not yet written any
software for them I was testing with the supplied Windows GUI configuration
tool (no source supplied, of course).  It is a .NET 2.0 application and
I had installed it (along with the .NET 2.0 framework) on Windows/98SE
(which is indeed supported by .NET 2.0).  It mostly worked but could
not launch the VideoLAN Client.  I asked them how they were trying to
spawn the VLC executable.  Rather than answer the question in a useful
way he first told me that my computer would be too slow to display the
video (in spite of the fact that I had initially pointed out that if I
started VLC manually it worked fine to display the video).  Then when I
told him that the machine was a 2.8GHz P4 he said I shouldn't be running
Windows/98SE on such a machine and should immediately upgrade to XP which
would be fully compatible with anything I might want to run.  When I pointed
out that XP would not run any of the VxDs I load on 98SE and that in any
case I did not want to upgrade, the conversation ended.

Analysis of the Windows GUI configuration tool revealed that they were using
the UNICODE version of the CreateProcess call and were not including the
necessary thunk layer to work on non-UNICODE operating systems.  I was able
to patch it well enough for my initial test purposes...

| "You are welcome to continue using the firmware already in the unit."
|
| How very nice of them.

Yes, that gave me a warm fuzzy feeling.  It's good to know I'm allowed
to use the hardware I bought.

| It's those kind of replies that give tech support a
| bad name.  That almost implies that they're being nice to you and could
| demand you stop using the unit if you didn't upgrade.  Worse yet, their
| "phone home" plan could contain elements of MS's Genuine Windows anti-piracy
| bushwa where they can knock out your machine remotely if they suspect you of
| criminal malfeasance.

I have the default gateway on the HDHRs set to a machine that does not
exist, but if they are clever I suppose they could snoop on other traffic
and find a way to the Internet.

| My favorite part of the thread?  "Wow; what other product do we own where we
| get direct answers from the actual Designers/Developers within an hour of
| posting!!! Thanks guys, good to know!!!"

Yeah, at first I thought he was a shill considering that the initial non-answer
took 4 days and was (I suspect) finally prompted by my inserting the question
in a few other threads...

| The answers to your questions happened to be some of the most INdirect I've
| ever seen.

So it goes...

| What are the odds that they'd confess they had a visit from the DRM law
| dogs?

Well, I'd expect that if they were really on our side (as they sort of
implied in the past) and there was no explicit gag order they would make
the information public to gain support.

| > The primary use of the HDHR is as a tuner for various recording software,
| > so yes, I'd say it is likely that owners will be recording programs. :)
|
| As if there's anything I've seen yet worth recording. (-:  I would think
| they'd have a better chance of evading draconian DRM concerns because
| there's no recording device built into their box,

I don't think so.  The broadcast flag proposals have always been about
preventing receivers from producing an unencrypted representation of
the "protected" material that they receive (even though the material
is broadcast in the clear).  The conventional channels of concern are
Firewire (for stand-alone set top boxes) and the PC bus itself (for
tuner cards).  Ethernet is just another transport medium.  Making the
recording devices secure is an afterthought to enable the selective
recording of some material once the recording device has established
that it will not let the material out of the DRM cage.  Receivers
with integrated recording devices are far less of a concern since they
do not need to expose the digital video outside the box.

				Dan Lanciani
				ddl@danlan.*com