WinTV-CI / Cinergy-USB-CI und ddci2

  • Ja, dasselbe Modul mit derselben Karte. Die Optionen sind


    Code
    1. # wintv-ci options
    2. options wintv_usb2ci use_dma_coherent=0
    3. options wintv_usb2ci dummy_half_uframes=3
    4. options wintv_usb2ci fx2_movx_stretch=6

    Ich nutze zillerbaers softhddevice-drm (per streamdev-server fuunktioniert das einwandfrei).


    Die Meldungen sehen so aus:



    Und es kommt das:


    Code
    1. Apr 27 22:53:04 raspberrypi kernel: [ 855.256544] wintv_usb2ci: * TS[0,15#14/3] not SYNC[42]: [94 cd 78 86 17 b0 db 0f ...]Apr 27 22:53:04 raspberrypi kernel: [ 855.256553] wintv_usb2ci: * TS[0,15#15/0] not SYNC[42]: [4f 13 c2 85 bb ba f7 99 ...]Apr 27 22:53:04 raspberrypi kernel: [ 855.256562] wintv_usb2ci: * TS[0,15#15/1] not SYNC[42]: [88 2d 7a e2 e7 68 71 43 ...]Apr 27 22:53:04 raspberrypi kernel: [ 855.256572] wintv_usb2ci: * TS[0,15#15/2] not SYNC[42]: [82 87 05 02 1e f2 b2 d1 ...]Apr 27 22:53:04 raspberrypi kernel: [ 855.256581] wintv_usb2ci: * TS[0,15#15/3] not SYNC[22]: [61 11 68 f2 90 b0 e7 91 ...]Apr 27 22:53:04 raspberrypi kernel: [ 855.256593] wintv_usb2ci: * TS[0,0#0/0] not SYNC[42]: [21 02 c3 52 33 b1 6a 02 ...]Apr 27 22:53:04 raspberrypi kernel: [ 855.256603] wintv_usb2ci: * TS[0,0#0/1] not SYNC[42]: [73 07 f8 09 1c 48 a8 81 ...]Apr 27 22:53:04 raspberrypi kernel: [ 855.256613] wintv_usb2ci: * TS[0,0#0/2] not SYNC[42]: [4e 60 e6 98 10 78 63 6d ...]Apr 27 22:53:04 raspberrypi kernel: [ 855.256622] wintv_usb2ci: * TS[0,0#0/3] not SYNC[42]: [14 f7 a2 0e 49 e7 06 59 ...]


    Ich erhalte aber kein Bild.


    LG,

    beta

  • Ja, du bekommst überhaupt keine brauchbaren Daten, das Sync-Byte - oder zumindest ein Byte mit dem Wert 0x47 - ist bei den "not SYNC " Zeilen immer 42 Bytes entfernt.

    Verwendest du die letzte Version 0.3.4pre3 von github ? Wenn ja, versuche zusätzlich noch diesen Modulparameter

    options wintv_usb2ci sync_urb_to_uframe=1 (default = 0 (off))
    und vielleicht auch noch

    options wintv_usb2ci urb_iso_asap=2 oder options wintv_usb2ci urb_iso_asap=0 (default = 1)

    LG Helmut

  • Ja, ich verwende die letzte Version vom Github. Die Sync-Fehler verschwinden, wenn ich ein "Optimum" für die Parameter einstelle. Ich erhalte trotzdem kein Bild und das Syslog ist mit diesen Meldungen voll:


    Code
    1. Apr 28 08:45:32 raspberrypi kernel: [34294.754618] wintv_usb2ci: ts_urb_complete : TS CAM-IO: +20
    2. Apr 28 08:45:32 raspberrypi kernel: [34294.761658] wintv_usb2ci: ts_urb_complete : TS CAM-IO: +30
    3. Apr 28 08:45:32 raspberrypi kernel: [34294.848631] wintv_usb2ci: ts_urb_complete : TS CAM-IO: +24
    4. Apr 28 08:45:32 raspberrypi kernel: [34294.857634] wintv_usb2ci: ts_urb_complete : TS CAM-IO: +64
    5. Apr 28 08:45:32 raspberrypi vdr: [softhddev] invalid PES audio packet
    6. Apr 28 08:45:32 raspberrypi kernel: [34294.962645] wintv_usb2ci: ts_urb_complete : TS CAM-IO: +24
    7. Apr 28 08:45:32 raspberrypi kernel: [34295.032655] wintv_usb2ci: ts_urb_complete : TS CAM-IO: +26
    8. Apr 28 08:45:32 raspberrypi kernel: [34295.039654] wintv_usb2ci: ts_urb_complete : TS CAM-IO: +28
    9. Apr 28 08:45:32 raspberrypi kernel: [34295.074768] wintv_usb2ci: ts_urb_complete : TS CAM-IO: +466


    Oder so etwas:


    Code
    1. Apr 28 08:49:10 raspberrypi kernel: [34513.371831] wintv_usb2ci: ts_urb_complete : TS CAM-IO: +20
    2. Apr 28 08:49:11 raspberrypi kernel: [34513.383936] wintv_usb2ci: ts_urb_complete : TS CAM-IO: +114
    3. Apr 28 08:49:11 raspberrypi vdr: [4417] [softhddev]Clear:
    4. Apr 28 08:49:11 raspberrypi vdr: [4417] ERROR: 1 TS packet(s) not accepted in Transfer Mode
    5. Apr 28 08:49:11 raspberrypi vdr: [softhddev] invalid PES audio packet
    6. Apr 28 08:49:13 raspberrypi kernel: [34513.482976] wintv_usb2ci: ts_urb_complete : TS CAM-IO: +208
    7. Apr 28 08:49:13 raspberrypi kernel: [34515.660487] wintv_usb2ci: ts_urb_complete : TS CAM-IO: +32


    Ab und an, ganz selten erhalte ich für Bruchteile einer Sekunde grünen Pixelmüll und "den Hauch von Audio", was dann aber sofort wieder verschwindet.


    LG,

    beta

  • Da gehen zu viele Pakete auf dem Weg zum/vom Modul verloren - ich vermute fast alle. Da muß ich etws nachdenken.

    Du erhälts noch (viel) mehr Debugausgaben, wenn du in wintv-ci-ci.c in Zeile 57 und 58 die beiden defines auf 1 setzt,

    Code
    1. /* a lot of TS in/out massages */
    2. #define DEBUG_TS_IO 0
    3. #define DEBUG_TS_IN 0
    4. #define DEBUG_TS_SYN 1

    und auch dei Moduloption options wintv_usb2ci show_ts_bitrate=1verwendest.

    Vielleicht sieht man dann besser, wo auf dem Weg die Pakete verloren gehen.

    Ändert die Auswahl des USB-Anschluß irgend etwas? (es wird aber vermutlich keinen Unterschied machen)

    LG helmut

  • Der Wechsel des USB-Anschlusses ändert nichts. ich habe fast das Gefühl, dass es am USB2 des Raspi noch etwas schlimmer ist als am USB3.

    Ich liefere ein Log mit dem o.g. Optionen so schnell wie möglich nach.


    Danke, dass Du Dir das ansiehst.


    LG,

    beta

  • Ich habe mir jetzt das syslog angesehen und es sind mir doch einige Dinge aufgefallen:

    Um 19:08:27 startet der Datentransfer zum CI, die Daten die zurückkommen sind noch verschlüsselt, und nach ca. 1 Sekunde wird für fast jeden zweiten Microframe (enthalt 4 TS-Pakete) die Länge 0 - also leer angegeben. Anhand der Continuity-Counters erkennt man, dass damit tatsächlich 50% der TS-Pakete fehlen.

    Ab kurz vor 19:08:46 stimmt etwas mit den TS-Daten die an das CAM gesendet werden nicht mehr - die ersten 4 Bytes ergeben keinen regulärer TS-Header. Das kann aber nichts mit dem WintvCI zu tu haben, denn die vom Treiber selbst eingefügten TS-Null Pakete kommen korrekt wieder aus dem CI. Außerdem wird immer noch nichts entschlüsselt - möglicherweise stimmt etwas mit dem Plugin nicht.

    Wie ist es mit FTA-Programmen - laufen die ohne Probleme, bzw. gibt das ci-Plugin keinen Fehler aus?


    Im Anhang ein Patch der auch Microframes mit Länge 0 verarbeitet - möglicherweise sind die fehlenden TS-Pakete doch vorhanden. Kannst du damit noch einmal ein Log erstellen.

    Und - du hast es vermutlich eh schon ausprobiert - einmal mit options wintv_usb2ci dummy_half_uframes=2 testen. So geht es bei meiner SMIT auch.

    LG Helmut

  • Danke, Helmut. Ich komme erst morgen dazu, Deine Patches einzuspielen und ein neues Log zu erzeugen.

    FTA-Programme laufen ohne Probleme. Allerdings habe ich auch da viele Ci-Meldungen, bevor die Sender loslaufen.


    Welches Plugin meinst Du (mit dem etwas nicht stimmt)? softhddevice-drm?


    LG,

    beta

  • HelmutB


    Nochmal vielen Dank, dass Du da dran bleibst. Das ist ausgesprochen nett von Dir.

    Ich habe ein neues Log mit Deinen beiden patches hier hochgeladen (History HD).


    ddci2 und ciminus habe ich von meinem Intel-System kopiert, um sicher zu sein, dass alle privaten libs dabei sind und funktionieren.

    Auf Intel läuft das einwandfrei.


    LG,

    beta

  • Deine Plugins sollten schon passen, das war ein Gedankenfehler von mir.


    Zum Log - in den Microframes mit Länge 0 sind keine brauchbaren Daten, es gehen tatsächlich so viele Pakete verloren.

    Und nach ca. 10 Sekunden sind die Daten auch nicht mehr als TS-Pakete zu erkennen (obwohl im 1.Byte immer das Sync-Byte (0x47) zu sehen ist - das bedeutet nichts, das ist nur eine Eigenheit des SMIT-Moduls).


    Was mir jetzt noch einfällt, wäre es mit options wintv_usb2ci use_dma_coherent=1 zu versuchen, da bin ich aber nicht sicher, ob das auf ARM-Platformen überhaupt verwendet werden soll oder kann.

    Und mitoptions wintv_usb2ci dummy_half_uframes=2 , 1 oder 0.

    Den cidebug-Patch kannst du wieder herausnehmen.


    LG Helmut

  • HelmutB


    Ich schon wieder :)

    Ich habe unter meinen Odroid N2+ ein CE (19.3) laufen. Darunter läuft ein chroot mit Ubuntu 20.04 und VDR mit dem Plugin von jojo61.

    Ich habe mir wintv-usb2ci-ko als Kernel Objekt im CoreElec build mitbauen lassen (cross-compiler). Beim insmod unter CoreElec geschieht folgendes:



    Der Rechner startet dann neu.


    Hast Du eine Idee, wo die null-Pointer Dereferenzierung herkommt?


    LG,

    Rudi

  • Ich kann einen segfault nur provozieren, indem ich das usb-ci bei laufenden VDR abstecke. Dann greift ts_poll() ins Leere. Es erfolgt aber kein Neustart, und wenn ich es wieder anstecke ist es nach dem CAM-Reset wieder normal verwendbar. Es muß bei bei Dir also an etwas anderem liegen.


    Ich kann jetzt nur raten. Vielleicht geschieht es beim Zugriff auf das ca-Device.
    Wenn der Aufruf wintv_usb_ci_show_sw_info(wintvci) in wintv-ci-core.c auskommentiert wird, sollte vor einem segfault noch die Meldung "probe successfull" angezeigt werden.

    Kannst du das mit dem Patch im Anhang einmal ausprobieren.

    LG Helmut