Digital Devices: cascaded CAM support (4 Viewers)

[Freuli]

Hello,

I recognized a problem. I have two DD cine-s2 cards in my server. One v5 and one v6. On each I have a CI Modul.
In the first CI I have a Alphacrypt with ORF card. In the second I have a Maxcam twin v2 with sky.
Following problem. If both CI moduls are in, I have no picture for ORF on one dd card. If I put out the maxcam ORF is working. If I switch the CIs moduls in the CI devices of DD, everything is working proberly with both cards and all CIs in. I will attach some logs
1: Alphacrypt in and Maxcam out, tune ORF1HD
2: Alphacrypt in and Maxcam in, tune ORF1HD
3: switched the both CI Moduls, tune ORF1HD

Right now I found out, that is also enough to pull out the sky card out of the modul to let ORF1HD running.

Thanks
Markus

 

[mm1352000]

Hello Markus

From the TV Server perspective all the log files look very similar. I can see a short burst of continuity and no payload errors in 1 and 3:

19-12-2013 15:42:20.923 Recorderid 780 , No PayLoad, Continuity Counter should be the same ! e ( prev 3 )
19-12-2013 15:42:20.939 Recorderid 780 , No PayLoad, Continuity Counter should be the same ! b ( prev e )
19-12-2013 15:42:20.985 Recorderid 780 , No PayLoad, Continuity Counter should be the same ! d ( prev b )
19-12-2013 15:42:20.985 Recorderid 780 , No PayLoad, Continuity Counter should be the same ! e ( prev d )
19-12-2013 15:42:21.79 Recorderid 780 , No PayLoad, Continuity Counter should be the same ! b ( prev e )
19-12-2013 15:42:21.110 Recorderid 780 , No PayLoad, Continuity Counter should be the same ! 5 ( prev b )
19-12-2013 15:42:21.110 Recorderid 780 , No PayLoad, Continuity Counter should be the same ! 6 ( prev 5 )
19-12-2013 15:42:21.110 Recorderid 783 Continuity error... 3 ( prev b ) - bad signal?
19-12-2013 15:42:21.173 Recorderid 780 , No PayLoad, Continuity Counter should be the same ! b ( prev 6 )
19-12-2013 15:42:21.204 Recorderid 780 , No PayLoad, Continuity Counter should be the same ! 2 ( prev b )
19-12-2013 15:42:21.204 Recorderid 780 , No PayLoad, Continuity Counter should be the same ! 9 ( prev 2 )
19-12-2013 15:42:21.235 Recorderid 780 , No PayLoad, Continuity Counter should be the same ! a ( prev 9 )
19-12-2013 15:42:21.251 Recorderid 783 Continuity error... b ( prev 3 ) - bad signal?
19-12-2013 15:42:21.329 Recorderid 780 Continuity error... 8 ( prev a ) - bad signal?
19-12-2013 15:42:21.329 Recorderid 783 Continuity error... a ( prev b ) - bad signal?

...but nothing in 2.
Could you please provide the TsReader logs as well?

mm

 

[Freuli]

Hello mm,

here they are. The test cases are the same then before.

Thanks and kind regards
Markus[DOUBLEPOST=1387486389][/DOUBLEPOST]Only an idea without having programing background. It seems, that the system thinks it is possible to decode with the sky card in the maxcam.

Regards
Markus

 

[mm1352000]

Only an idea without having programing background. It seems, that the system thinks it is possible to decode with the sky card in the maxcam.

Yeah, I'd probably agree with that.
When we ask for the channel to be decrypted, we don't specify the CAM/CI to use because we have no way to know which CAM is capable of decrypting each channel. For TVE 3.5 I created a DD plugin which allows you to specify a list of providers that each CAM supports. Then by matching the channel provider with the CAM provider we can ask only the right CAM to decrypt the channel. For TVE 3 there is no solution...

 

[Freuli]

Ok, but why it is working if I change the ci moduls in the ci devices?[DOUBLEPOST=1387488469][/DOUBLEPOST]TV 3.5, for when it is scheduled? Is it for MP2?
Thanks

 

[mm1352000]

Ok, but why it is working if I change the ci moduls in the ci devices?

From what I know or guess about how the DD drivers work...
When we ask the tuner to try to decrypt a channel, it tries each CAM/CI slot in sequence until it finds one that claims that it can decrypt the channel. After that it stops.
You can see the relevant code here:
https://github.com/MediaPortal/Medi...lAccess/DigitalDevices/DigitalDevices.cs#L439

As the comment (from me) says:

We apply the request to the first CI filter in the graph and the driver will automatically try all of filters to see if any of them can decrypt the service.

My guess is that the first CI filter is the Maxcam when your order is {Alphacrypt, Maxcam}. Therefore the Maxcam receives the decrypt request first. If it says that it can decrypt the channel then I guess the Alphacrypt is not tried. When you switch the CAM order the Alphacrypt is tried first and it really can decrypt ORF. Also, the Alphacrypt must not claim that it can decrypt Sky channels so that the DD driver tries the Maxcam for those channels. In that way everything can work.

For some CAMs I know it is possible to edit the list of CA systems that the CAM supports. I can do this with my Orion X-CAM premium. If you were able to do that with the Maxcam then maybe you could configure it so that it doesn't say that it can decrypt ORF.

Please keep in mind that a lot of these comments are "educated guesses". I have never seen the DD driver code and never had a situation myself where I could try such a test.

TV 3.5, for when it is scheduled? Is it for MP2?

It is already released as "alpha" with MP2. An MP1 release is planned at some point, but no fixed schedule. It will be released when it is ready.

 

[Freuli]

Your guesses sounds logical.
Is MP2 already stable enough to get used in daily use?

 

[mm1352000]

Is MP2 already stable enough to get used in daily use?

I don't know. I run XP so I can't install or try it. Also, each person has their own definition of "stable enough"...
You can install MP2 alongside MP1... so I suggest you try the alpha 4 release with Native TV when it is released... soon.

 

[Freuli]

Good morning and happy new year to all! I am looking forward to the patch for 1.6 final. Thanks!
Markus

 

[Freuli]

Hello,

I don't want to be annoying but is there an estimated release date for 1.6 final with cascaded cam support available?

Thanks
Markus