[linux-dvb] Re: Problems with WinTV NOVA-CI

[Andrew de Quincey <adq_dvb@lidskialf.net>]

On Tuesday 14 Dec 2004 11:23, Werner Hauger wrote:
> On Tue, 14 Dec 2004 10:23:24 +0000, Andrew de Quincey
>
> <adq_dvb@lidskialf.net> wrote:
> > On Tuesday 14 Dec 2004 09:38, Werner Hauger wrote:
> > > On Mon, 13 Dec 2004 13:20:31 +0000, Andrew de Quincey
> > >
> > > <adq_dvb@lidskialf.net> wrote:
> > > > I also never saw this behaviour when I was developing the budget_ci
> > > > driver for the TT Nova-S-CI.
> > >
> > > Yes, I know from the mailing list archives that you developed the
> > > budget_ci driver. Thank you for taking the time to make this card
> > > fully supported under Linux. But this also means you would be the best
> > > person to ask about my second problem. I know the CI init code is
> > > still commented out, so what are the reasons/problems ? Did you test
> > > VDR with the CI code ? As stated in my first post, it works fine on
> > > the first channel, but subsequent channels only work when the CAM is
> > > reset after a channel switch. What debugging info can I enable/add in
> > > the driver to help locate the problem ? I get the feeling the CAM does
> > > not respond properly any more after going into the decoding state.
> >
> > Are you using 2.6? If so, CVS HEAD has had the CAM stuff uncommented for
> > a long time with various bug fixes for crashes and timeouts.
>
> No, 2.4. I have seen this in the CVS HEAD comments, and applied all
> the relevant bug fixes to the 2.4 code. Now the timeout messages are
> gone and the link layer failure does not occur any more, but after
> switching channel, nothing happens. Screen stays black, no error
> messages. Only after a certain time VDR complains : ERROR: no useful
> data seen within 10552440 byte of video stream.
>
> > When you say reset the cam, what do you mean exactly?
>
> In VDR under the CICAM menu there is a Reset option. Calling that
> prints the following line in the logs: dvb_ca: DVB CAM detected and
> initialised successfully. This exactly the same message as when the
> driver first loads.

I've never actually used VDR myself - the code I use always resets the CAM 
when changing channel. 

AFAIK the ci driver is unlikely to be causing this - all it does is exchange 
data from the higher layers. The ci driver is analogous to an ethernet 
driver, and the higher EN50221 layers (in VDR) to a TCP/IP stack. 

VDR should probably reset the CAM when changing channels - I'm not quite sure 
what will happen if it isn't - _very_ likely it will vary from CAM to CAM. 
The FF cards have a radically different implementation of the CI interface 
which may be doing this reset automaticaly, which is likely why VDR doesn't 
do it itself as most people appear to use it with a FF card.

Hmm, or perhaps the CI driver should reset the CAM automatically on a 
retune... but that might cause other problems. My feeling is it should be up 
to the userspace application to reset CAMs when appropriate - anyone have any 
comments?