[go: up one dir, main page]

Jump to content

Talk:CableCARD

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Mexico

[edit]

Does someone know if Mexico supports CableCard? Whpq 07:04, 5 June 2008

"CableCard 2.0" Boxes Deployment

[edit]

It's great if somebody can work this into the article. - http://www.multichannel.com/article/CA6492390.html?rssid=196 —Preceding unsigned comment added by 72.66.19.230 (talk) 02:21, 18 October 2007 (UTC)[reply]


Description of Integration Ban is not Detailed Enough

[edit]

Could someone with more familiarity on the topic expand on the concept of the integration ban? The current text seems to imply that cable companies as of 2007 were required to use CableCards just like third party devices like TiVo. Wikipedia articles shouldn't imply anything than can simply be stated.

Also, the text as it is doesn't explain why cable provided set-top-boxes have access to interactive content and video on demand which CableCard devices do not. —Preceding unsigned comment added by Gthiruva (talkcontribs) 01:35, 24 February 2010 (UTC)[reply]

CableCard 2.0 Deadline

[edit]

Doesn't the FCC have a drop dead date by which cable operators must start deploying CableCard 2.0 and using it themselves in their own set top boxes?

PoD?

[edit]

What does Point of Deployment mean? An esoteric word such as that should be quickly followed by a definition and some context. Hackwrench 05:11, 13 January 2006 (UTC)[reply]

An updated introduction that described the background, and origination, of the POD (now CableCard) would clarify this meaning. If someone doesn't beat me to it -- I will try to get to this one. I have some experience with the beginnings of the POD project. (Wiki writer 20:54, 19 June 2006 (UTC))[reply]
Updated intro helps -- but does not answer the POD question; i.e., the history of closed-system cable settop boxes, with their own proprietary conditional access and out-of-band (OOB; incl. return path) specs -- the POD allowed the point-of-deployment items (conditional access and OOB hw) to be inserted into a standard settop box with the cable system specific POD (now cablecard). ALSO - The CableCard is already part of OpenCable; Opencable does not supercede it. DCAS however may eventually supercede the need for a Cablecard, though I am not sure how the new specs address the OOB channel issue unless they assume that all settop box hardware will have both OOB modems on board (as already exists in newer settop chips), they will adopt a common OOB spec -- or they will use DOCSIS. (Wiki writer 15:43, 20 June 2006 (UTC))[reply]


Guides

[edit]

The article makes it seem like the one-way nature of v1.0 CableCards prevents programming guide functionality. This is obviously not a cause of the lack of such support, since virtually all satellite services are one-way but support programming guides. They do this by constantly streaming the data to all clients, so when a client wants a programming guide update, it simply listens until it has all the data it needs. Guspaz 00:09, 17 January 2006 (UTC)[reply]


--- Exactly. My set listens for TV Guide info over normal cable for my programming guide, although my CableCARD isn't authorized yet. My cable provider doesn't know how to use CableCARDs... I am getting a program guide though. Someone needs to rewrite that part of the article.

Controversies not mentioned

[edit]

No offence, but a cable company shill could have written the article as it stands today. I don't think the bias is necessarily intentional, because the cable companies are spending a great deal of effort to mold public opinion regarding cablecards in the interest of delaying requirements that they be required to use them in their devices. Folks may simply be repeating misinformation that has been served up by cableco representatives in the media.

-There is a great deal of controversy between the Cable Companies vs. Consumer Electronics companies, Cableco's versus the FCC, Cableco's versus consumers. None of this is mentionned, and the article makes it appear that what is known as cablecard 2.0 will in fact be the successor of what is now known as cablecard 1.0. Unlike CC1.0, the FCC has not agreed to the specification, and the cable companies who wrote the spec have failed to secure any support for it among the consumer electronics companies who would be implementing the spec. The CEA and consumer groups would like to see specs for support of interactivity to proceed very differently. Essentially, the problem they see with the CC2.0 spec is that it turns the electronics box into a bot that is compelled to accept only the Java programs that the the cable companies force download to it. This is unacceptable to CE companies because distinguishing features of their devices could be submerged or ignored by these controlling cableco "OCAP" programs. Consumer groups feel that such control over these products makes CE companies try to find favor with the cable companies rather than consumers, thus reducing the power of the consumer to promote choice.

My opinion is that the highly contentious positions should be treated in Wikipedia as any other contentious issue like Roe is handled. NPOV while accurately describing both sides of the controversy. -Mak 02:46, 26 December 2006 (UTC)[reply]

Rewrite

[edit]

I made a significant rewrite. Didn't include all the issues that the CEA and NTCA squabble over, but added tons more dimension and reference to important FCC documents. More to be done- I still have to wade through some of my tortured prose. I made some repetitions and neglected much of the technical section in favor of attempting to get through the layman's explanation of features.

Areas having to do with future directions are closely related to Cablecard 2.0 discussion which must necessarily be close to explanation of what cablecard 1.0 is. However, I broke up some of this so that it didn't become a black hole sucking people down into details without completing a sufficient overview. Not sure how to better handle that. -Mak 23:03, 27 December 2006 (UTC)[reply]

1.0 Does NOT Support Interactive features.

[edit]

The section on 1.0 cable cards listed them as supporting pay-per-view *and* program guides. This is simply not the case. While some televisions (such as pioneer plasma tv's) *do* support an interactive guide, this information does *not* come from the cable company.

Also, although pay per view itself, as it was originally created, was not interactive, pay-per-view on most cable systems, including the two largest providers, comcast and time warner, is no longer a "locked access" based service, but rather a "video on demand" based service.

Some of the confusion might stem from what are called "multi-stream" cable cards. These are no different from ordinary cable cards, aside from the fact that they allow decoding of two continuous streams, rather than one single continous streams. These are primarily for use with devices such as Tivo DVR's and other similar products, or TV's with built in DVR features. —The preceding unsigned comment was added by 67.170.69.53 (talk) 19:51, 9 February 2007 (UTC). I didn't sign, because I am not registered. ~ dreamwraith |AT| renevo |DOT| com[reply]

  • Re Guides and Pay per view: If you inserted the word "interactive" into your statement, you would be correct. Cable companies have begun introducing such interactive features and have suggested that Cablecard is irrelevant because it does not have these features. Yet program guides and pay per view are indeed available to cablecard users just as they are available to other cable customers the majority of whom also do not use these interactive features. In the case of Pay Per view, users may either order via phone or via the net. In the case of program guides- all cable companies I am aware of make a channel available with a guide. Yet the lack of an interactive program guide is irrelevant to DVR and PC users- Vista Media center, as well as dvrs from companies like Sony and Tivo all offer an interactive guide as part of their cablecard enabled products.
  • Re: MCards- Computers and DVRs are not the sole devices that require multistream cards. Most high end televisions have a picture in a picture feature which is fundamentally broken without an MCard. It will work only so long as the user remembers that they cannot use it to see a second channel if they are already using the Single stream cablecard for the channel they are viewing. How does the user know which channels are which? Well- they know when PIP stops working. -Mak 18:11, 3 March 2007 (UTC)[reply]

Trademark Use Question

[edit]

If "CableCARD" is a trademarked term, why does this article use "CableCARD" as a noun throughout? Trademarked terms are always adjectives modifying a generic noun. —The preceding unsigned comment was added by 204.176.49.45 (talk) 21:24, 24 April 2007 (UTC)[reply]

This is not true. Consider the noun "Coke". Metageek 15:13, 1 May 2007 (UTC)[reply]

ATI

[edit]

Is ATI a manufacturer of CableCard TV Tuner? --202.71.240.18 10:33, 3 May 2007 (UTC)[reply]

Yes. What they make is generically called an OCUR module and can only be attached to approved Vista MCE configurations. In other words you can't just go out and buy one and attach it as an upgrade. You have to buy a new box preapproved for OCURs. OCURs are also expensive (currently I think $1400 for the ATI model, and are large- not the kind of thing you'd put in a case under the TV alongside the dvd player. The OCUR article is empty. Maybe you could dig up a PD photo or make a fair use version an ATI OCUR photo and describe what OCURs are. -Mak 17:00, 4 July 2007 (UTC)[reply]

CableCARD 1.0 and Two-Way Interactive Features

[edit]

There seems to be a misunderstanding about the ability of CableCARD 1.0 to support two-way features. CableCARD 1.0 modules are two-way devices and DO support these features. Claiming that the CableCARD 1.0 module does not support these features is technically incorrect. This misinformation probably results from the fact that these features only work with an OpenCable Host 2.0 device. The inability to support two-way features is a deficiency in the host device and not the CableCARD module.[1]. I think a lot of consfusion is being created because there is some ambiguity about what is being talked about when CableCARD 1.0 is mentioned. Are you talking about the actual module or the host and the module as a complete package? I suppose since there has not been success in producing a CableCARD 1.0 module and host combination that allows two-way features it could be said that CableCARD 1.0 does not support these features. However, I still think it technically inaccurate to say that the CableCARD 1.0 module doesn't support the features.

It is a huge confusion, and perhaps the article could do a better job at confronting it. But really, in your question, you also are confusing the specification with the physical cards. "Cablecard 1.0" (the spec) does not support two way communication. Period. Any CE company that puts out a cablecard 1.0 host has to sign the DFAST agreement that prohibits them from doing two way. Period. As for Cablecard 1.0 modules (the cards)- these do not exist. As clearly stated in the article, the cards support both unidirectional and bidirectional communication. I am presuming here that what you are calling a "CableCard 1.0" module is an SCard or MCard.
Could you point to the passage that could do a better job? The article is explicit about the confusion that many folks have on this score: For example in the physical cards section:
"A common misconception is that there is a CableCARD 2.0 physical card that will provide two way services and will not be compatible with CableCARD 1.0 certified devices. This is not the case. CableCARD 2.0 host devices will only use either SCards or MCards that also work with CableCARD 1.0."
There is a passage that talks about the Cablecard 1.0 limitation in only supporting one way devices- is that the one that leads to the mistaken reading? -Mak 17:59, 11 August 2007 (UTC)[reply]
OK I might have missed line about the common misconception with the CableCARD 2.0 being a physical card when I wrote my comment. I think that helps with the confusion. However, I'm not sure what you mean by saying the spec does not support two way communication. I haven't read the spec in a while, but I fairly certain it does not define the physical product in such a way that prevents it from having 2 way communication, which seems to be what you are implying. The DFAST agreement is another matter entirely. Also, I do not know what you mean when you say CableCARD 1.0 modules do not exist. My use of the term CableCARD 1.0 module is done in order to be consistant with the terminology used by CableLabs in their primer. I could also say CableCARD device as defined in the specification. You can break the termonoligy down into S-Card and M-Card, but an S-Card can conform to either CableCARD 1.0 or CableCARD 2.0 with only single stream capability. I use the term CableCARD 1.0 module to make the distinction between the two.
I guess the question is whether it is accurate to potray CableCARD 1.0 and CableCARD 2.0 as being about the exclusion or inclusion of interactive two way features when infact the real issue influincing two way communication is the question of a Unidirectional Digital Cable Product host device as defined by the FCC and encumbered by the DFAST licence versus an OpenCable Host 2.0 licensed device that does support 2 way communication. While the CableCARD 1.0 interface specification and the CableCARD 2.0 interface specification are related to the types of host devices they are implemented with, the actual requirements that define the host device are not actaully a part of the 1.0 and 2.0 interface specifications. In other words, the "OpenCable Host 2.0 Device Core Functional Requirements" and the "CableCARD Interface 2.0 Specification" are two separate documents. When the terms "CableCARD 1.0" and "CableCARD 2.0" are used in the article, the assumption is that it is refereing to the interface specification, which means it is ignoring the entire other half of the equation in the form of the host requirements, and I would argue that it is this other half that is more important as far as two way communication is concerned. 131.30.121.23 17:17, 2 November 2007 (UTC)[reply]

"CARD"

[edit]

What does the C.A.R.D. stand for? If nothing, then we should render the name "Cablecard" or perhaps "CableCard" and the page should be edited and moved accordingly. We do not slavishly reproduce the bizarre capitalization used by trademark holders: WP:MOSTM. 170.140.210.108 (talk) 18:10, 28 May 2008 (UTC)[reply]

^^^ Amen. I don't see any mention *anywhere* in the article of what "CARD" stands for. As such, I call shenanigans. See also Citgo, Dish Network, Wal-Mart, etc. 68.248.194.149 (talk) 22:20, 27 July 2010 (UTC)[reply]

Possible edit/dispute

[edit]

I have an issue with the first paragraph that mentions "Another name for a CableCARD is an M-CARD on some cable boxes."

M-CARD means that it is a multi-stream cableCARD. S-CARD means that it is a single-stream cableCARD.

M-CARD is not another name for cableCARD for the same reason that French is not another name for human. — Preceding unsigned comment added by 216.231.158.26 (talk) 16:44, 6 January 2012 (UTC)[reply]

Current FCC rules

[edit]

The article mentions that some cable companies require on-site installation CableCards. While technically correct, this is incomplete at best and misleading at worst. The new FCC rules are specific that that if the CableCo permits end-user installs of ANY equipment, then it must permit end-user installs of cableCards. This rule dates all the way back to October 2010 and was published here: http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-10-181A1.pdf There are continued anecdotal reports of CableCos violating this rule (see, for example, this review: http://www.amazon.com/review/R3RJQD9PV95GDL/ref=cm_cr_dp_title?ie=UTF8&ASIN=B004HKIB6E&nodeID=172282&store=electronics ) Since the rule has been in place for quite some time, it seems curious that this article is not clearer on this subject. — Preceding unsigned comment added by 156.110.167.90 (talk) 16:11, 10 May 2012 (UTC)[reply]