WinTV-CI / Cinergy-USB-CI und ddci2

    Hi,

    the next-1a.diff was thought only for the Diablo Cam, which was working before next-1.diff.

    The only new for this CAM was the read and dump of the Attribute Memory Area. None of my CAMs had any problem with it.


    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    Hi Helmut,

    looks like you did catch it, since git from today also the Matrix CAM Air did work on my wintv-ci.

    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    Hi Helmut,

    I do have still a issue with my Cinergy CI where the Cingery firmware get loaded and I do have only a rev 2.0

    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    Hi Helmut.

    the Cinergy CI is working now also

    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    I just uploaded a update to github. The firmware patch can be applied on both the wintv and cinergy firmware v2.

    And i reduced the COR timeout back to the 15 sec. firmware default as the MatrixAir times aut anyway.

    Yuri666 : there is now a module option uf_triggers_submission ro set it to a higher value for the use with minisatip.


    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    Edited once, last by HelmutB ().

    Like 2

    9000H Good !

    The #define USB_COR_TIMEOUT in core.c could probably set to 5000 (5s) to avoid unnessary delays for CAMs not responsing correct. My slowest responding CAM needs between 2,5 to 3.0 seconds at this stage.

    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    Hello Helmut,

    I have troubles with new CAM. In authentication process from CAM receive big tpdu (more 2kbyte). With old CAM it works fine.

    Code
    [36462.589347] [CAM ] rb_read_tpdu (0)(1)[2683] *** (7) 9F9003 ***

    Full log:

    old CAM


    But with new CAM i have error

    new CAM

    New CAM with ordinary dvb ci and kernel drivers works fine too.

    Can you look please, where might be bug?


    BR,

    Yuri

    Hi Yuri,
    for me it looks like some kind of race condition between a CAM request ('cc_data_req' after a 5 second delay) and the regulary polled CI status from the driver.

    Does this occur on every (new) CAM initilalization or only once and then ?

    But I will check it.

    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    The driver itself polls the CAMs status byte only every 2 seconds to detect insertions/removes, and you can change it here:

    Code: wintv-ci-ca.c
    ca_dev->ca_task.delay = HZ * 2; /* 2 sec */

    But VDR itself regularly queries the the CAM by writing short PDUs to see if the CAM has some data to send,

    And for this writes the status byte has to be read too. I dont know how often these queries are done, you could check it by insert a pr_info("...") at the beginning of the function ca_write() (line 554).

    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    I think see the problem:

    Code
    [  546.143489] CI_read_CMD_REPLY   : [06] 0/0/0
[  546.143500] CA_recv_TPDU : *** ERROR *** TPDU too large (frag_size = 18446744073709551614 > 4094)

    The CAM report that it has some data for the host, the CAM status-byte indicates "data ready" but the actual read gives 0 bytes of data. And as CA_recv_TPDU() does not expect zero-len data this ends in an error.

    I will send you a first patch tonight.

    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    Hallo Yuri,
    I think your new CAM ignores the negotiated buffersize of 255 bytes and send the data in 256 byte-blocks without notifying the driver.

    The Old CAM fills the buffer of 255 bytes in thsi way (4 x 60 + 15 bytes)

    Code
    [36462.365365] CI_read_CMD_REPLY   : [06] 255/60/195
[36462.397236] CI_read_CMD_REPLY   : [06] 195/60/135
[36462.429354] CI_read_CMD_REPLY   : [06] 135/60/75
[36462.461349] CI_read_CMD_REPLY   : [06] 75/60/15
[36462.493342] CI_read_CMD_REPLY   : [06] 15/15/0

    And your new CAM (4 x 60 +16 bytes)

    Code
    [95684.661847] CI_read_CMD_REPLY   : [06] 0/0/0 --> means 256/60/196
...
[95684.693988] CI_read_CMD_REPLY   : [06] 196/60/136
[95684.725924] CI_read_CMD_REPLY   : [06] 136/60/76
[95684.757780] CI_read_CMD_REPLY   : [06] 76/60/16
[95684.789930] CI_read_CMD_REPLY   : [06] 16/16/0

    I use a buffersize of 255 bytes because there is only a 8-bit size-field in the msg-header (0..255).

    But when i assume, that a 0-byte TPDU never can occure, then i can increase the drivers buffersize to 256 bytes.


    I will modify the driver in this way and post the patch tomorrow.

    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    Hallo Yuri,

    I've seen it. It is still the old problem that when stopping the TS-stream sometimes a kind of unsync of IN / OUT packets remains. And then CA-messages can not be sent to the CAM. I already have a patch trying to restore this sync, but this one is not fully tested with all my CAMs yet and it will take some time. But I can post a pre-release version today or tomorrow.

    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login