[linux-dvb] Re: budget-ci CI interface testing

[Kenneth Aafløy <keaafloy@online.no>]

On Friday 23 April 2004 03:06, Andrew de Quincey wrote:
> > Well, I've tested it some more now but I'm still unable to get the
> > decryption going. Free channels work nicely and I get data from
> > scrambled channels too but it's not getting descrambled :(
> >
> > I've only tested this with MythTV. Since I'm currently not in front of
> > the machine, the best I can do for now is try to get a recording going.
> > This is what I get in the log:
>
> [...]
>
> > CAM: Conax 4.00e, 01, 0B00, 04B1
> > 2004-04-22 23:56:17 DVB#0 CAM - Sending PMT to slot 0.
> > ERROR: CAM: Read failed: slot 0, tcid 1
> >
> > 2004-04-22 23:56:44 DVB#0 WARNING - Transport Stream Continuity Error.
> > PID = 700
> > 2004-04-22 23:56:44 DVB#0 WARNING - Transport Stream Continuity Error.
> > PID = 701
> > 2004-04-22 23:56:46 DVB#0 WARNING - Transport Stream Continuity Error.
> > PID = 700
> > 2004-04-22 23:56:46 DVB#0 WARNING - Transport Stream Continuity Error.
> > PID = 701
> > CAM: Conax 4.00e, 01, 0B00, 04B1
> > ERROR: CAM: Read failed: slot 0, tcid 1
> >
> > 2004-04-22 23:57:10 DVB#0 WARNING - Transport Stream Continuity Error.
> > PID = 700
> > 2004-04-22 23:57:10 DVB#0 WARNING - Transport Stream Continuity Error.
> > PID = 701
>
> [...]
>
> > dvb_ca: DVB CAM detected and initialised successfully
> > dvb_ca: DVB CAM detected and initialised successfully
> > dvb_ca: DVB CAM detected and initialised successfully
> > dvb_ca: DVB CAM detected and initialised successfully
> > dvb_ca: PC card did not respond :(

FYI, MythTV is using the ci code from VDR, and that is what does the reset 
whenever the CAM fails to respond after 3500ms (iirc).

> I assume this must be MythTV resetting the CAM when it gets the read
> errors. The only time a read can fail is as follows:
>
> 1) If a buffer < 2 bytes is supplied during the read, the driver will
> return -EINVAL.
> 2) If nonblocking mode is enabled, and there is no data, it will return
> -EWOULDBLOCK.
> 3) If a signal occurs interrupting the driver when it is attempting to
> acquire the lock on the read buffer.
> 4) If an invalid buffer pointer is supplied the driver will return -EFAULT.

The VDR CI code uses poll to check for data on the CAM fd. If this timeouts 
(default is 3500ms, iirc) or the Reply is unfamiliar, the library schedules 
the reset sequence. Check this function for more info, where also the timeout 
also is declared right above it (dunno if that is the case in the VDR 
version, but I assume so):
int cCiTransportConnection::RecvTPDU(void)

> Of course another other possibility is that the read() isn't failing and
> MythTV is actually reporting a timeout error here. Try enabling full debug
> mode in the driver to see more detail... otherwise its time to start
> hacking printfs into mythtv...

Also there is some lines in MythTV's VDR code, look in dvbdev/dvbci.cpp for 
the lines below, and change them to '* = true;':
static bool DumpTPDUDataTransfer = false;
static bool DebugProtocol = false;

> As to why you get the final "PC card did not respond" error... the CAM must
> not like being reset so many times in a row.... I'll have to see if I can
> sort that one out.

Might just be an iteration of a previous bug?

> > I don't know if it's related but the Myth backend abends pretty often
> > while trying to record scrambled channels. No log message or anything,
> > it just dies... :-(
> >
> > Obviously the recordings don't work, the files stay at 0 kb.
> >
> > Is there some lower level tool to test the decryption so I can make sure
> > this is not some MythTV bug?
>
> Dunno... anyone?

Just so you are aware of the fact: MythTV works fine here, with a Conax 
(4.0<something>) cam on a Nexus-S which stops reponding now and then, 
dvbci.cpp does the reset and it's back in buisiness. What really disrupts 
stuff here is when the ARM crashes...

-- 

Kenneth Aafløy
keaafloy@online.no


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.