Slow channel changes on 6 ETH

[golfdude]

does anything in the log here explain what is causing the slow change, about 12 seconds from input to actual viewing:

Jan 1 07:32:12 ocur[21]: ocur: [3] Attempting to SetChannel (Channel=762 SourceId=0 Mode=0)
Jan 1 07:32:12 ocur[21]: upnp: [192.168.1.15] Action(cas[3]) SetChannel success
Jan 1 07:32:12 ocur[21]: ocur: Disabled table monitor for instance 3
Jan 1 07:32:12 ocur[21]: ocur: [3] Program number set to 0, was 702
Jan 1 07:32:12 ocur[21]: ocur: [3] Starting TA[6] resolve for channel 762
Jan 1 07:32:12 ocur[21]: libcetontrif: trif[6] Found channel 762 in map
Jan 1 07:32:12 ocur[21]: ocur: [3] Adding pid 0x0000
Jan 1 07:32:12 ocur[21]: ocur: [3] Resolved channel 762 -> freq 543000, prog 762, modulation 16
Jan 1 07:32:12 ocur[21]: ocur: [3] Tune to 762 (mod=q256, freq=543000, program=762, std=9)
Jan 1 07:32:12 ocur[21]: ocur: [3] Program number set to 762, was 0
Jan 1 07:32:12 ocur[21]: ocur: Disabled table monitor for instance 3
Jan 1 07:32:13 ocur[21]: ocur: [3] Locked: 1 Acc E: 0
Jan 1 07:32:13 ocur[21]: ocur: [3] Adding pid 0x1ffb
Jan 1 07:32:14 ocur[21]: ocur: [3] Adding pid 0x0030
Jan 1 07:32:14 ocur[21]: ocur: [3] Adding pid 0x0129
Jan 1 07:32:14 ocur[21]: ocur: [3] Adding pid 0x0230
Jan 1 07:32:15 ocur[21]: ocur: [3] Tune finished to freq 543000
Jan 1 07:32:15 ocur[21]: ocur: [3] Getting pmt for program 762
Jan 1 07:32:15 ocur[21]: ocur: [3] Adding pid 0x0329
Jan 1 07:32:15 ocur[21]: ocur: [3] Adding pid 0x1000
Jan 1 07:32:15 ocur[21]: ocur: [3] Got pmt for program# 762
Jan 1 07:32:15 ocur[21]: ocur: [3] Adding pid 0x0529
Jan 1 07:32:15 ocur[21]: ocur: [3] Adding pid 0x0629
Jan 1 07:32:15 ocur[21]: ocur: [3] Adding pid 0x0829
Jan 1 07:32:15 ocur[21]: upnp: Event(tuner[3]): PCRLock, "1"
Jan 1 07:32:15 ocur[21]: ocur: [3] Adding pid 0x0620
Jan 1 07:32:15 ocur[21]: ocur: [3] Adding pid 0x062f
Jan 1 07:32:15 ocur[21]: ocur: [3] Adding pid 0x0621
Jan 1 07:32:15 ocur[21]: ocur: [3] Adding pid 0x0623
Jan 1 07:32:15 ocur[21]: ocur: [3] Adding pid 0x0626
Jan 1 07:32:15 ocur[21]: ocur: Disabled table monitor for instance 3
Jan 1 07:32:15 ocur[21]: ocur: Enabled table monitor for instance 3
Jan 1 07:32:15 ocur[21]: ocur: [3] Channel is scrambled, expecting CCI
Jan 1 07:32:15 ocur[21]: ocur: [3] Sending ca_pmt to CableCARD for program number 762 index 0
Jan 1 07:32:20 ocur[21]: ocur: WARNING: [3] Timed out waiting for CCI (recvd 0)
Jan 1 07:32:21 ocur[21]: ocur: [3] CCI 00 arrived for program# 762
Jan 1 07:32:22 ocur[21]: ocur: [3] CCI 00 arrived for program# 762
Jan 1 07:32:23 ocur[21]: upnp: [192.168.1.15] Get(tuner[3]): Frequency "543000"
Jan 1 07:32:24 ocur[21]: upnp: [192.168.1.15] Get(mux[3]): ProgramNumber "762"

[Crash2009]

does anything in the log here explain what is causing the slow change, about 12 seconds from input to actual viewing:

Jan 1 07:32:15 ocur[21]: ocur: [3] Sending ca_pmt to CableCARD for program number 762 index 0
Jan 1 07:32:20 ocur[21]: ocur: WARNING: [3] Timed out waiting for CCI (recvd 0)
Jan 1 07:32:21 ocur[21]: ocur: [3] CCI 00 arrived for program# 762
Jan 1 07:32:22 ocur[21]: ocur: [3] CCI 00 arrived for program# 762
Jan 1 07:32:23 ocur[21]: upnp: [192.168.1.15] Get(tuner[3]): Frequency "543000"
Jan 1 07:32:24 ocur[21]: upnp: [192.168.1.15] Get(mux[3]): ProgramNumber "762"

9 of your 12 seconds are in this section. I Yahooed "WARNING: [3] Timed out waiting for CCI (recvd 0)" and ended up back here http://www.thegreenbutton.tv/forums/vie ... =68&t=6729

It appears that either your CableCARD is no good or you haven't found the correct technician. Either way call your cable company and start yelling!

[JohnW248]

A major factor is the TA

Jan 1 07:32:12 ocur[21]: ocur: [3] Starting TA[6] resolve for channel 762

The frequency has to be returned from the TA and any problem there will impact channel change. Also the HD handling video buffer will also impact channel change, first tune after a computer has been "at rest" from an extender will take longer especially if you have an external drive attached, etc.

But I would start with the TA, the channel decrypts, then likely the cableCARD is good since many functions of the cableCARD are taken over by the TA when you're on a SDV system.

[th83]

I removed some extra splitters in my setup, getting the signal strength from -4dBi to up around 0dBi, this seems to have helped a lot for me (though I don't have a TA).