Need a little help for the TT API for a CAM issue

[StephaneM 1]

Hi,

 

I need some help for a strange CAM issue.

 

I created a BDA recording application that does work with TT card and I manage the CI with TT API. I use personally a CT-3650 with a CAM (PowerCAM version 2.0) and I have no issues with it, works great.

 

However I recommended to one of my users to buy a CT-3650 and the same CAM I use but he have an issue with its CAM.

 

The CAM is a PowerCAM version 4.6. and eventhough the TT API is returning for CA change a 0x0E reply with a 0 status the CAM is not decrypting anything.

 

What's odd is that if it uses a PowerCAM version 2.0 (instead of the version 4.6), then it works fine, channels are decrypted.

 

If the PowerCAM 4.6 is used with TT-Viewer the channels are also decrypted.

 

So I guess I am doing something wrong but honestly I don't see where the error is...

 

Here is what I'm doing: a standard BDA graph, with

 

* DVB-T Network Provider

* USB 2.0 BDA DVB-T Tuner

* USB 2.0 BDA DVB-T Capture

* InfTee

* MPEG2 Demultiplexer (MS)

* MPEG2 Transport Information Filter (MS)

* My Own Demuxer

 

Before running the graph I:

 

1) Open TT hardware (bdaapiOpenHWIdx)

2) Open the CI (bdaaOpenCI with full callbacks)

 

Then I submit tune request, run the graph and:

 

1) Upon receiving the PMT in my demux, get the CI slot status (bdaapiCIGetSlotStatus)

2) Wait for the TT callback to notify that the slot is ok with a CI_SLOT_MODULE_OK or CI_SLOT_CA_OK (and it did with something like:

 

CI slot 0 changed

CI Status:SlotModuleOk

CI Text : PCAM V4.6

CA System ID : 4AA1

CA System ID : 100

CA System ID : 500.....)

 

3) Finally request the channel to decode with either bdaapiCIReadPSIFastDrvDemux or bdaapiCIMultiDecode passing along the correct SID for the channel.

 

4) Wait for CA change to give the 0x0E reply with 0 status and finally stop the TIF filter and goes one with capturing all the packets

 

And here I am: with PowerCAM v2.0 = all is fine, with PowerCAM v4.6 = nothing is decoded (but the CAM works fine in a TV or with TT-Viewer on the same machine...)

 

Is TT-Viewer / DVBViewer using the exact same TT functions or another ones?

 

Best Regards,

Stéphane.

[Lars_MQ 81]

We stopped using the SID Methods with the TT drivers because they didn't work for some users. Instead we're using now bdaapiCIReadPSIFastWithPMT.

[StephaneM 1]

We stopped using the SID Methods with the TT drivers because they didn't work for some users. Instead we're using now bdaapiCIReadPSIFastWithPMT.

Ok, thanks for this, I'll try it and hopefully it will fix the issue.

 

Best Regards,

Stéphane.

[StephaneM 1]

Instead we're using now bdaapiCIReadPSIFastWithPMT.

FYI, in this case I think the CI method used was not the source of the issue.

 

For an unknow reason, after receiving the "SlotModuleOk" message, sending the PMT (or SID) with the TT API and receiving the CA change Ok message, I receive another CI Change "SlotModuleOk" message (without me using the CIGetSlotStatus API...) approx. 2 sec. later.

 

I ended resending the PMT / SID upon receiving this CI change message and now it works... So is this how you are supposed to hande the TT API : sending the PTM / SID to be decoded for each "SlotModuleOk" message?

 

Regards,

Stéphane.

[Lars_MQ 81]

Well we don't ask for getslotstatus, since it is sent automatically after initializing the CI...

[StephaneM 1]

we don't ask for getslotstatus, since it is sent automatically after initializing the CI...

I only use it once at the begining. Maybe it's enough to cause this strange behavior, I'll have to test it.

 

With other CAM upon receiving the SoltModuleOk and sending the PMT/SID => decryption is done, no more slot change messages are received.

 

With this particular CAM, 2 sec. after sending the PTM/SID (upon receiption of the first SlotModuleOk and receiving the CA change Ok) another SlotModuleOk is received (so approx 15 sec. after I initially called CIGetSlotStatus at the very begining of the process)... and if I don't resend the PMT/SID nothing is decrypted... It is like the CAM is resetting itself all alone... this is strange.