[mythtv-users] Comcast CableCard Info

Tue Aug 2 19:53:11 UTC 2011

On Tue, Aug 2, 2011 at 8:53 AM, Ronald Frazier <ron at ronfrazier.net> wrote:
> 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.

I am, eventually, able to tune all my CCI=0 channels, and my
experience matches yours. I'll compile in those changes and see if
they help, but it sounds more like a really large band aid for a cut
that won't coagulate.

I'm wondering if it's not worth going to the last firmware that sounds
like it worked fine, until a new one can be released that may
hopefully fix this issue? I will also submit a ticket with them about
the issue.

Luckily, so far none of my scheduled recordings seem to have had an issue.

-- 
Steve
http://www.mythtv.org/wiki/User:Steveadeff
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette