InfiniTV 6 ETH issues with CCI Timeouts?

[fossilz]

So, I have had the InfiniTV 6 ETH for two months and not had it working properly yet. I was at the point where I wanted to just send it back, however out of the blue I got a call from a Charter Representive who asked me if I was ever able to get my InfiniTV 6 working. I stated no, nobody had any idea why. She wanted to work with me before I sent it back. She sent a tech to the house and they replaced the CableCARD, and Tuning Adapter again, this is the third time. We seemed to make a little progress with this CableCard.

I'm using the latest Beta Firmware (13.10.28.177) and the Diagnostics Tool still Reports the CableCard isn't validated, however now it seems to show that a Channel Map was received (in the past it didn't get that far). I truely believe the CableCard is validated, others have reported this firmware shows the CableCard not validate but it still works.

What I see in the logs when I go to a channel like ESPNHD is the following:

Code: Select all

Jan  1 00:09:56 ocur[21]: ocur: [3] Attempting to SetChannel (Channel=803  SourceId=0  Mode=0)
Jan  1 00:09:56 ocur[21]: upnp: [192.168.0.7] Action(cas[3]) SetChannel success
Jan  1 00:09:56 ocur[21]: ocur: Disabled table monitor for instance 0
Jan  1 00:09:56 ocur[21]: ocur: [3] Program number set to 0, was 0
Jan  1 00:09:56 ocur[21]: ocur: [3] Starting TA[6] resolve for channel 803
Jan  1 00:09:56 ocur[21]: libcetontrif: trif[6] Found channel 803 in map
Jan  1 00:09:56 ocur[21]: ocur: [3] Resolved channel 803 -> freq 825000, prog 14, modulation 16
Jan  1 00:09:56 ocur[21]: ocur: [3] Tune to 803 (mod=q256, freq=825000, program=14, std=9)
Jan  1 00:09:56 ocur[21]: ocur: [3] Program number set to 14, was 0
Jan  1 00:09:56 ocur[21]: ocur: Disabled table monitor for instance 0
Jan  1 00:09:56 ocur[21]: ocur: [3] Adding pid 0x0000
Jan  1 00:09:56 ocur[21]: ocur: [3] Locked: 0 Acc E: 0
Jan  1 00:09:56 ocur[21]: ocur: [3] Adding pid 0x1ffb
Jan  1 00:09:56 ocur[21]: upnp: [192.168.0.7] Calling Action(fdc[3]) RequestTables
Jan  1 00:09:56 ocur[21]: upnp: [192.168.0.7] Action(fdc[3]) RequestTables success
Jan  1 00:09:56 ocur[21]: upnp: [192.168.0.7] Calling Action(ua[3]) SetCurrentTunerUseReason
Jan  1 00:09:56 ocur[21]: ocur: [3] UA: use_reason 2 TA: use_status 0
Jan  1 00:09:56 ocur[21]: upnp: [192.168.0.7] Action(ua[3]) SetCurrentTunerUseReason success
Jan  1 00:09:57 ocur[21]: ocur: [3] Tune finished to freq 825000
Jan  1 00:09:57 ocur[21]: upnp: Event(cas[3]): DescramblingStatus, "Unknown"
Jan  1 00:09:57 ocur[21]: ocur: [3] Getting pmt for program 14
Jan  1 00:09:57 ocur[21]: ocur: [3] Got pmt for program# 14
Jan  1 00:09:57 ocur[21]: ocur: [3] Adding pid 0x0030
Jan  1 00:09:57 ocur[21]: ocur: [3] Adding pid 0x0035
Jan  1 00:09:57 ocur[21]: ocur: [3] Adding pid 0x0031
Jan  1 00:09:57 ocur[21]: upnp: Event(tuner[3]): PCRLock, "1"
Jan  1 00:09:57 ocur[21]: ocur: [3] Adding pid 0x07c0
Jan  1 00:09:57 ocur[21]: ocur: [3] Adding pid 0x0430
Jan  1 00:09:57 ocur[21]: ocur: [3] Adding pid 0x07c1
Jan  1 00:09:57 ocur[21]: ocur: [3] Adding pid 0x07c2
Jan  1 00:09:57 ocur[21]: ocur: [3] Adding pid 0x07c3
Jan  1 00:09:57 ocur[21]: ocur: Disabled table monitor for instance 0
Jan  1 00:09:57 ocur[21]: upnp: [192.168.0.7] Get(tuner[3]): Frequency "825000"
Jan  1 00:09:57 ocur[21]: ocur: Enabled table monitor for instance 0
Jan  1 00:09:57 ocur[21]: ocur: [3] Channel is scrambled, expecting CCI
Jan  1 00:09:57 ocur[21]: ocur: [3] Sending ca_pmt to CableCARD for program number 14 index 1
Jan  1 00:09:58 ocur[21]: upnp: [192.168.0.7] Get(mux[3]): ProgramNumber "14"
Jan  1 00:09:59 ocur[21]: ocur: [3] Carrier lock is 1
Jan  1 00:10:01 ocur[21]: ocur: WARNING: [3] Timed out waiting for CCI (recvd 0)

I'm trying to figure out what could cause that Timed out message? This happens on ALL channels outside of my local channels. Any channel that is scrambled basically.


Any input from someone else who may have experienced this before?


Thanks

[mdavej]

I still don't believe it's validated. The Diag tool may not show the correct status, but the web diagnostics and the status inside of WMC is correct. So check those before you assume it's validated.

Techs are as clueless about cable cards as everyone else at Charter. So you just have to keep trying over the phone until you find someone who knows how to set up a cable card. Make sure you give them the Card ID, Host ID and Data, and that they enter all these numbers in their system then send a hit. Don't hang up until you see that it's validated and that you can tune any channel.

I've been through this many, many times with Charter. You can eventually get it working once you find the right person.

[fossilz]

It's all working now. A new CableCARD(4th one) and a person on the Charter side who knew what to do and BAM. So wonderful!

[erkotz]

in most cases, a CCI timeout is a symptom of an incorrectly-provisioned CableCARD and not the root cause.