Project

General

Profile

Bug #6060

PCMCIA Data rate command hangs CI CAM

Added by Enigma131 enig over 3 years ago. Updated almost 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Descrambling
Target version:
-
Start date:
2021-06-02
Due date:
% Done:

0%

Estimated time:
Found in version:
all versions
Affected Versions:

Description

I have wrong command for normal CI CAM ( not CI+ compatible cam)

2021-06-02 08:14:58.073 [ TRACE] en50221: dvbca0-0: pcmcia data rate set to 00
2021-06-02 08:14:58.073 [ TRACE] en50221: dvbca0: write
2021-06-02 08:14:58.073 [ TRACE] en50221: 00 01 A0 0A 01 90 02 00 02 9F 80 24 01 00 ...........$..
2021-06-02 08:14:58.577 [ ERROR] en50221: dvbca0-slot0: communication stalled for more than 500ms

Look at this peace of code:

in src/input/mpegts/en50221/en50221_apps.c :

app->cia_info_version = atag & 0x3f ;  // 0x9F8021 / 0x9F8022 / 0x9F8023 with mask 0x3f gives: 0x21/22/23
CICAM_CALL_APP_CB(app, cisw_appinfo, atag & 0x3f, s, type, manufacturer, code);
if (app->cia_info_version >= 3) /* at least CI+ v1.3 / <------------ *is always true ......
if (CICAM_CALL_APP_CB(app, cisw_pcmcia_data_rate, &rate) >= 0)
return en50221_app_pdu_send((en50221_app_t *)app, CICAM_AOT_PCMCIA_DATA_RATE, &rate, 1, 0);

so I had to modify correct value :

app->cia_info_version = atag & 0x0f ;

History

#1

Updated by Flole Systems over 3 years ago

What about the line right after the one you changed:

CICAM_CALL_APP_CB(app, cisw_appinfo, atag & 0x3f, s, type, manufacturer, code);

?

#2

Updated by Enigma131 enig over 3 years ago

I had modified my line in bold and it works.

The problem is for line:
if (app->cia_info_version >= 3) /* at least CI+ v1.3 /

The condition is always true, because app->cia_info_version is: 0x21/22/23

Your line above is unchanged in case of Ci+ compatible Cams.

Perhaps more complex code can be done, but as is, it isen't working for my Cam.

#3

Updated by Flole Systems over 3 years ago

Yes I understand that, but the line I quoted is getting the "wrong" value aswell. I am just wondering: Does it need changing aswell or is it supplying the correct/expected value to the function called?

#4

Updated by Enigma131 enig over 3 years ago

Hum good question. I havent Ci+ compatible CAM to test ...

#5

Updated by Flole Systems over 3 years ago

I just checked https://dvb.org/wp-content/uploads/2019/12/a173-2_ci_plus_2_-_part_2.pdf and apparently the atag is always the same for each version and only the ressource identifier is changing? Do I see that correctly? That ressource identifier would be 0x41, 0x42, 0x42... and with & 0x3f that would be exactly 0x01, 0x02.....

Also in https://dvb.org/wp-content/uploads/2020/02/En50221.V1.pdf the 9F 80 24 isn't mentioned?

#6

Updated by Enigma131 enig over 3 years ago

Yes, 9F 80 24 isn't mentioned in EN50221 because it isn't a CI command.
Look at your CI+ link, Table A1 page 25, Application information, it is defined only in CI+ clause 11.1
What I suggest:
made the modifiation as i have wrote in post 1, I think it is OK for all cases (Ci and Ci+)
And in case it is not ok whith a CI+ case, you can debug whith a real CI+ compatible case

#7

Updated by Anonymous over 3 years ago

Enigma131 enig wrote:

Why useless ?
Problem is still not solved to my case.

I had a lot of issues with CI/CI+CAMS last year. In the end i had to accept that support for EN50221 whithin tvh is incomplete. Unfortunatly a lot of experience is missing.

If your patch works in your setup: good. Don't expect more.

#8

Updated by Flole Systems over 3 years ago

I cleaned up all comments that don't belong to this issue. Please stop using the issue tracker as a place for personal discussions. Thanks.

#9

Updated by Enigma131 enig almost 3 years ago

Sill waiting for a solution. In mean time, I have forked git to my github

Also available in: Atom PDF