[mythtv-users] Comcast encrypting World Series on FoxHD

[Gary Buhrmaster]

On Wed, Nov 5, 2014 at 7:09 PM, Ronald Frazier <ron at ronfrazier.net> wrote:
...
> A few weeks later, my cable company finally figured out they can lock the
> cablecard firmware version (to a version that does report the CCI: Copy
> Freely flag), so I switched back to the ceton.

Since that ability is documented in the Cisco admin guides
(and typically most companies use the ability to roll out test
firmware to special customers) it really should not have taken
over a month.  More likely it was either that their (administrative)
processes did not have a way to make the exceptions stick
and be marked accordingly so that the next time an upgrade
happens you do not end up starting all over again (which would
suck for you) [internal "back end" processes are easily more
complex to build, test, and implement than the gui cablecard
configuration manager Cisco offers (point, click, and change
everyone at once)], or that your cable company does not have
a well exercised internal engineering escalation path (you got
buried in referral hell and it took some time to get the right
people involved).  But at this point, it does not really matter,
since they figured it out.

> In my emails with ceton, as I recall, they did say they had requested to be
> able to ignore CGMS at one point in the past and were shot down, but with
> the latest changes they were in processing of updating and resubmitting the
> request to cable labs.

And SD has also said they are asking for additional
"clarification" regarding this new implementation (they
also said they tried before, and failed, but I think it
was different in the details, and they are trying a new
approach with different rationale).  We can only hope
that Ceton and SD and Hauppauge are talking and
that a united approach might work well for all customers
[enlightened self interest here, of course].

> I don't have much confidence cablelabs would actually
> agree with any sort of change like that

The change (itself) regarding allowing (although not
requiring, as I recall) that CCI=copy_freely to turn into
CCI=not_specified (which allows CGMS to take
control) was stated to have been explicitly requested.
I strongly suspect (but its just a guess) that some
content providers want more control, and the MSOs
requested that a technical proposal be made and
approved for future contractual compliance reasons
(I really can not see the MSOs asking for the changes
in both the specifications and by Cisco/Arris/Conex/etc.
to implement something they did not intend to use or
offer to use).

I would agree that it seems unlikely that it is going to be
changed back as part of a formal specification update.
What *might* happen (and this has nothing to do with
CableLabs itself) is that the various management tools
default differently so that new capabilities default to
old behavior, which would mean that cable companies
(really, their customers) would not be "surprised" by
a new firmware roll out as what apparently happened
this time (at least WOW suggested they were caught
unaware).  It is one thing to make an intended change
(at any time WOW could choose to set (almost) all
content to be copy-once just like TWC does today;
there is nothing in the laws prohibiting that choice to
be made), and quite another when it surprises a cable
company (and its customers).  From all documented
interactions between the cable companies and the
customers, so far not one cable company has stated
that impacting the customer access to the content was
intentional (although the Sn hatted might claim that they
are simply delaying that announcement until after the
fait accompli).

>  unless they had someone big like
> comcast or microsoft pushing on them about it.

I would imagine that Microsoft does not really care
((a) they implement protected path so it is a mostly
moot issue, and (b) MCE/WMC is a dead product
anyway (well, technically not dead, just "no future
improvements")).