[mythtv-users] Comcast CableCard Info

Ronald Frazier ron at ronfrazier.net
Tue Aug 2 12:53:41 UTC 2011


On Tue, Aug 2, 2011 at 1:14 AM, Steven Adeff <adeffs.mythtv at gmail.com> wrote:
> sadly, the latest patch doesn't seem to help my tuning problem.
>
> let me know if I can provide any info for you.

I want to make sure we are talking about the same problem (I think we
are). First, I want to verify that you can tune all of the channels in
question at least SOME of the time. If you can't, there might be a
different issue. Assuming that's the case, try channel surfing until
you get to a case where it stops working. When that happens, I'd like
you to take a peek in the Ceton's web interface, and look at the
status for the tuner you were using. What you should see is that the
Channel field is set to the channel you tried to tune, but the Program
Number and PIDs fields both say 0. If so, that's the same problem I'm
seeing. If you then go to the tuner tab and tell it to Set Channel to
the same channel again, it will reattempt the tuning (and hopefully
succeed). If your frontend is still waiting in live TV, it should
start playing within a few seconds of a successful tuning.

So assuming that's the case, as I said, the problem is that when you
change the channel, the web interface at first fills in all the fields
as you would expect it to, but then a short while later the Program
Number and PIDs revert to 0. When I first saw this happen, it happened
rather quickly (within 1 second), so I added code that makes sure
those values stick for about 3 seconds, and that's what's in the patch
I put out last night. That seemed to nearly eliminate the problem for
me, but I did some more testing this morning, and I found a case where
it took about 4 seconds for the Ceton to switch those numbers back to
0. So this morning I up it to making sure it sticks for 10 seconds,
and that seems to have made it better (though my testing was limited
this morning).

If you want to try and make this change to your own code (before I
release a new patch), here's what you can do. If you go into the
libs/libmythtv/cetonhttpmanager.cpp file, find the following line in
the TuneVChannel function

settings->verifications_required = 3;

and change it from 3 to 10. Also, looking at my logs, it seems there
can be a several second delay before it attempts to retune. I think I
know how to eliminate that, but I'm not able to test it (I'm not at
home at the moment). If you want to go ahead and try the untested fix
for that, feel free (I'm nearly certain it won't cause any problems).
In the same file, go into the run() function and change

if ((time_before_rechecking > 0) && (time_before_rechecking < max_sleep))

to

if ((time_before_rechecking >= 0) && (time_before_rechecking < max_sleep))


To be clear, this isn't going to stop the Ceton from failing to
tune...it's simply going to detect when it happens and then
re-initiate the tuning request. So the bigger question is, why is the
Ceton failing to tune. I looked at the card's log (in the web
interface, on the Log tab). When I had the failed request, here is
what I found. In the following lines, you'll see each line has a
number in brackets (ex: [1]). I believe this indicates

First failed attempt:

123885.567869: ocur: cas_hal_TuneChannel:2942 : [1] Tune to 264
(mod=q256, freq=705000, program=264, std=9)
123885.568858: ocur: mux_SetProgramVariable:1781 : [1] Program number
set to 264, was 0
123885.639648: ocur: tuner_SetUntranslatedFrequency_ex:609 : [1] Acc E: 0
123885.790933: ocur: mux_pid_union:323 : [1] Adding pid 0x1efd
123886.040661: ocur: tuner_SetUntranslatedFrequency_ex:679 : [1] Tune
finished to freq 705000
123886.041790: ocur: cas_GetPatPmtAndPids:1892 : [1] Getting pmt for program 264
123891.251641: ocur: cas_GetPatPmtAndPids:1958 ERROR: [1] No pat returned
123891.252360: ocur: cas_SetChannel_delay:2471 WARNING: [1] Could not get pmt
123891.252981: ocur: cas_SoftDisableVideo:2257 WARNING: [1] Disabling video
123891.253587: ocur: mux_SetProgramVariable:1781 : [1] Program number
set to 0, was 264


Second failed attempt:

123906.101337: ocur: mux_SetProgramVariable:1781 : [1] Program number
set to 0, was 0
123906.102504: ocur: cas_hal_TuneChannel:2942 : [1] Tune to 264
(mod=q256, freq=705000, program=264, std=9)
123906.103494: ocur: mux_SetProgramVariable:1781 : [1] Program number
set to 264, was 0
123906.136303: ocur: tuner_SetUntranslatedFrequency_ex:609 : [1] Acc E: 0
123906.137395: ocur: cas_GetPatPmtAndPids:1892 : [1] Getting pmt for program 264
123911.142016: ocur: cas_GetPatPmtAndPids:1958 ERROR: [1] No pat returned
123911.142737: ocur: cas_SetChannel_delay:2471 WARNING: [1] Could not get pmt
123911.143359: ocur: cas_SoftDisableVideo:2257 WARNING: [1] Disabling video
123911.143968: ocur: mux_SetProgramVariable:1781 : [1] Program number
set to 0, was 264


Third attempt which finally succeeded:

123912.459106: ocur: mux_SetProgramVariable:1781 : [1] Program number
set to 0, was 0
123912.460773: ocur: cas_hal_TuneChannel:2942 : [1] Tune to 264
(mod=q256, freq=705000, program=264, std=9)
123912.461787: ocur: mux_SetProgramVariable:1781 : [1] Program number
set to 264, was 0
123912.515529: ocur: tuner_SetUntranslatedFrequency_ex:609 : [1] Acc E: 0
123912.516637: ocur: cas_GetPatPmtAndPids:1892 : [1] Getting pmt for program 264
123912.645653: ocur: cas_GetPatPmtAndPids:1928 : [1] Got pmt for program# 264
123912.646993: ocur: mux_pid_union:323 : [1] Adding pid 0x1ffc
123912.648381: ocur: mux_pid_union:323 : [1] Adding pid 0x1e20
123912.649661: ocur: mux_pid_union:323 : [1] Adding pid 0x0040
123914.085499: ocur: Event(tuner[1]): PCRLock, "1"
123914.088490: ocur: mux_pid_union:323 : [1] Adding pid 0x0000
123914.089827: ocur: mux_pid_union:323 : [1] Adding pid 0x0041
123914.112468: ocur: mux_pid_union:323 : [1] Adding pid 0x004d
123914.113773: ocur: mux_pid_union:323 : [1] Adding pid 0x0042
123914.121062: ocur: cas_SetChannel_delay:2524 : [1] Channel is
scrambled, expecting CCI
123914.121750: ocur: cas_SetChannel_delay:2533 : [1] Sending ca_pmt to
CableCARD for program number 264 index 0
123914.927139: ocur: cas_NotifyCopyControlBits:1183 : [1] CCI 00
arrived for program# 264


So you can see, it looks like the Ceton's tuning system is failing to
find the PAT and PMT packets. I don't know why this would happen. It
could be a case where my cable provider is spacing these packets out
further apart than the card bothers to look, and thus it gives up
before the next one comes in. I think I'm gonna have to send this info
to Ceton and get a response back from them about it.

Whatever that cause, it seems like this is out of my control, and I
can only attempt to detect it and retune. I could try to figure out
the DRI interface and try using that to set it. However, my gut
feeling (and I could be wrong) is that the DRI and web tuning both
actually use the same backend tuning code.

-- 
Ron Frazier


More information about the mythtv-users mailing list