[mythtv] Possible timing issue between dvbchannel and dvbcam

[Kenneth Aafløy]

On Thursday 30 September 2004 02:15, Taylor Jacob wrote:
> > The last time you said that your comhem set-top-box also showed this
> > message, it will still be treated as a broken CAM by me, anyone else?
> 
> From that posting I found what at the time I thought was a bug in the PMT 
> handling, but now I KNOW its a bug.  I said bytes, but i meant bits. For
> starters a DVB PID is bounded from 0-1FFF, so there is that patch that needs
> to be made, which I can make later tonight. I suspect this will not solve
> your problem though. 

Sure, 13 bits, of which the rest of the word is reserved and should be '0', 
but it would not hurt to mask it. I was under the impression that someone 
made a patch back then, but I must have been mistaken. I think I did the 
change in my tree, but that's rm *'d.

> Kenneth: You also can have multiple encryption systems used for 1 service. 
> I have seen this myslef, and also how would you do a cam swap if you
> couldn't support 2 systems?

Well, channels can be encrypted with multiple encryptions and cams can support 
multiple encryptions, but only one would be used at a time to decrypt the 
stream. So what needs to be done is either have some clever matching code in 
there or let the user direct the channel to a particular cam him/her self. 
The latter is what VDR does, but I guess most cases could be easily 
autodetected so that the least user invention is necessary.

> It is possible that the ordering of the CAIDs in the PMT is causing problems
> for his cam module? 

I was under the impression that the cam actually starts decoding the stream 
but starts 'displaying' this message and eventually resets? The current code 
in myth will only send pmts that the cam claims to be able to decode, so if 
the cam supports for example both conax and viaaccess and the channel also is 
encrypted with both these systems there could be a problem. But he claims to 
have a viaaccess cam, and they do not put their rivals encryption system into 
their own product.

> There is a comment you made in the cam code about having to handle CAPIDs
> more like VDR does. Kenneth is there any way to query the CAM and ask what
> systems the CAM supports? If not I will have to handle this in my code
> changes. 

The VDR cam handling provides a list of ca system ids, which is matched with 
the ca system id of the ca_descriptors in the dvbcam class.
ciHandler->GetCaSystemIds();

> I don't know that the threading is to blame since it looks like it would
> only affect killing off the CAM, but either way Issac is right it needs to
> be re worked so I guess I will add that to my long list of code fixes to
> make?

It's making use of Qt's signals (even though trolltech claims that they are 
not thread safe), which will call the functions from it's own thread. So I'm 
missing what argument hes trying to prove.

> Kenneth: Isn't the cam code lifted from VDR that is in myth anyway?

That is very correct Taylor, but I have made some minor modifications to it.

Anders, you could try to change the lines in dvbcam.cpp that says:

        if (ciHandler->NeedCaPmt())
            first_send = true;

with

        //if (ciHandler->NeedCaPmt())
            first_send = true;

Which will make the code send the pmt array to the cam more often. You could 
also try to experiment with the value CPLM_FIRST in this line:

                cCiCaPmt capmt(chan_opts.serviceID, CPLM_FIRST);

you will find other CPLM_?? values in dvbdev/dvbci.h.

Just to add to the common knowledge here, I have one channel on Thor 1W that 
also shows this behavior (displays a 'no access' message when entering) but 
the cam happily decodes the channel anyways. The channel is 'VH1 Classic' and 
can be found at 12456 Mhz, 28000, Vertical. It's encrypted with the Conax 
system from Canal Digital Scandinavia.

Kenneth