Posts by HelmutB

    Das Ergebnis von 0223a ist besser als erwartet. Es wird auch beim FTA Programm das CAM angesprochen und Date/Time gesetzt - und das sogar recht schnell nach ca. 15s. Der NVC erkennt auch, dass das hier Daten unnötig durchs CAM geschickt werden FTA -> THROUGH CAM! und später No CA descriptors in CPL! Forcing through CAM (please make no SID request)... und

    CAM0: CA PMT for caid 776 sent successfully ! Das stört aber überhaupt nicht und wird außerdem nur beim ersten Tunen gemacht.


    Bei den beiden anderen Tests mit nur 15s VDR-Startverzöerung ist der NVC bzw. die CAM Erkennung zu langsam. Das Plugin kennt zwar die Tuner, weiss aber nocht nichts von den Camslots und antwortet voreillg mit Ready() = true.


    Daher ist die 35s Verzögerung notwendig, du kannst dafür aber mit 0.9.5j jeden beliebeigen Sender als Startkanal verwenden, Timeraufnahmen sollten immer in Ordnung sein. Vielleicht noch etwas ausgiebiger testen.

    Und wenn du noch 0x100 zur debugmask dazunimmst, wird von mcli-Plugin auch nicht mehr die Dummy-Pid 0 (=PAT-Pid) im TS-Stream aktiviert, das ist meiner Meinung nach unnötig.

    LG Helmut


    Ergänzung::

    Die "invalid lock sequence" dürfte irgendwie mit dem skindesigner-Plugin zusammenhängen.

    Zu 1) Ja, es geht nur um das erstmalige Benutzen der CAM (mit Empfang)

    Zu 2 ) Das sieht nach mehrfachen Wechsel zwischen dem EPG-Scan (20s) und Umschalten von VDR auf das Timer-Programm aus
    Zu 3) der EPG-Scan braucht keine verschlüsselden Daten, nur NIT, SDT, PAT PMT..., daher bringt es nichts.


    Statt einer 35s Startverzögerung und Umschalten auf Programm #1 von mcli sollte das Setzen des VDR-Startkanals auf einen verschüsselten Sender das gleiche Ergebnis bringen.


    Da du aber gerne mit SIXX starten willst, hier noch ein Versuch, bei dem VDR beim 1. Tunen dem Netcever auch FTA Progarmme als verschlüsselt angibt. Möglicherweise gehts auch so. Die debugmask dafür wäre 0x40df.

    LG Helmut

    Und mit dem mcli-0.9.5i Plugin die debugmask 0x1000 dazunehmen, dann startet das Plugin wieder Programm Nr.1 - und das sollte ORF1HD oder ein anderes verschlüsseltes Programm sein.

    Das Tunen 60s vor der Aufnahme wird nur gemacht um Devices aufzuwecken, eine Sat-Schüssel auszurichten o.ä. Es werden aber keine Stream-Pids angefordert - daher auch kein CAM-Zugriff.

    LG Helmut

    Ich glaube, so wie im letzten Log sind eine kurze 0000.ts mit 15s und dann die fehlerfreie 0002.ts das Beste, das du mit NUC und Netceiver bekommen kannst wenn du eine Aufnahme startest die den Netceiver-Camslot das erste Mal verwendet.

    Wenn im Netceiver dann auch noch Signalprobleme auftauchen können es auch 30s und ein paar zusätzliche Retunes mehr sein.


    Ein Unterschied zum ReelVdr ist, dass dieser einfach langsamer startet als der NUC.

    Beim ReelVdr switched das mcli-Plugin auf Kanal 1- das ist bei dir der verschlüsselte Kanal ORF1HD. Das haben wir aber im mcli-patch für den NUC abgeschaltet, weil hier das CAM noch nicht bereit ist (das dauert im NCV ungefähr 30-35s ).

    Beim ReelVdr geschieht dieses erstmalige Tunen aber erst ca. 60s nach dem Boot des NCV - da ist die Alphacrypt schon "Ready" und das Setzten von Date/Time setzen und das interne Retune geschieht schon jetzt. Bei NUC wird es erst beim Aufnahmestart durchgeführt.

    Code: ncv-log 0221a
    1. aktuelle Systemzeit NCV: 61 Sekunden |
    2. 00.CAM status (MMI MSG NO): READY (STACK : OK BUSY : 0) (MMI HDL/STA: 0/0/0) (TL: 0x20481000/1) (D/T: 1/61) TC_POLL failed: 0/0 Flags: 2/0x100/4
    3. Start Streaming PID 0 Tuner on slot 0 count 0 MCG ff18:3004:0:17c8:55f0:8022:72f8:6000, satpos 1992
    4. == Start 1.Programm => ORF1 HD

    ES bräuchte auch für den NUC eine Lösung die den camslot des Netceivers gleich nach den Boot initialisiert. Ich werde noch Nachdenken.

    LG Helmut

    Das ist ja gar nicht so schlecht. Kannst du ein paar Zeilen aus dem Syslog mit den "not sync" Meldungen posten.


    Durch "dummy_half_uframes" gibt es immer ein paar TS-pakete die nicht vom Transponder kommen. Eigentlich sollten es die vom Treiber eingefügten TS-Null Pakete sein. Sie werden aber aus irgendeinem Grund mit Unsinn überschrieben und daher nicht mehr richtig erkannt. Sie werden jedenfalls verworfen, kommen also nicht zum VDR.

    Ich werde überlegen, wie man diese - in deinem Fall unnötigen - Meldungen unterdrücken kann.

    LG Helmut

    can you please update the git?

    I will do it tonight or tomorrow.


    Edit: "urb_iso_asap" und "sync_urb_to_uframe" haben nur mit dem 3.4_pre1 Patch eine Funktion!


    Edit2: wenn du nicht warten willst, kannst du ja vorertst in "wintv-ci-ci.c" die Zeile #487 auskommentieren:

    pr_err(" * TS[%d,%d#%d/%d] not SYNC[%d]: [%*ph ...]\n", zero, urb->number_of_packets-1, i, j, s, 8, ts);

    Hast du trotz dieser "not sync" ein fehlerfreies Bld? Und tauchen sie sofort auf, oder erst nach ein paar Minuten?
    Um den VDR nicht beenden zu müssen, schalte auf ein FTA-Programm und mache ein CAM-Reset. Dann wieder zum verschlüsselten Programm. Kommen die Fehler wieder?


    Sonst die Parameter durchprobieren

    options wintv_usb2ci dummy_half_uframes=2 # 0, 1,2 oder 3 (0 geht auch!)

    options wintv_usb2ci fx2_movx_stretch=6 # 3..7, normalerweise von 5 bis 7

    und dann noch

    options wintv_usb2ci urb_iso_asap=2

    options wintv_usb2ci sync_urb_to_uframe=1


    LG helmut

    Es wird doch eine CI-Firmware geladen, allerdings die Version 1 bei der der MOVX Firmware Patch nicht geladen wird.
    Mit dem kleinen Patch im Anhang wird dei V2-Firmware erzwungen - es kann aber sein, dass sie nicht ganz zur Hardware passt.

    Einen Versuch ist es aber Wert.

    LG helmut

    Zu a) ja, wird nach 35s zurückgesetzt - mit der Meldung CAM 0: decrypts Channel 1 die habe ich allerdings in deinen Logs noch nicht gefunden - vielleicht braucht es doch noch eine Korrektur.

    Zu b) geht sicher, nur wo - es ist ja eher eine mcli Einstellung.

    LG helmut

    Bei mir: wintv_usb2ci: * FW_Version(2.01) FPGA_Version(1.d

    Die Firmware "0" ist keine CI-Firmware, nur die Minimal-FX2LP-Firmware zum Beschreiben der CAMs.

    Ich kann dir morgen einen Patch schicken, der testweise doch die 2er-Firmware lädt - vielleicht funktionierts.

    LG Helmut

    Du hast im ersten Eintrag die Caids ganz rausgelöscht und ein Feld zuwenig, daher daher SID 1 statt SID 4911 - das Programm gibt es aber nicht.

    Wenn du "0:" einsetzt, aktualisiert VDR wieder alle Caids so wie in deinem letzten channels-Eintrag.


    ORF1 HD;ORF:11303:HC23M5O35P0S1:S19.2E:22000:1920=27:0;1921=deu@106,1922=mis@106:1925:0:4911:1:1007:0


    LG Helmut

    Hier das Diff zu usb2ci-0.3.4pre1. Es gibt zwei neue Modulparameter in wintv-ci-ci.c.

    Vielleicht hilft es bei dir.

    LG Helmut

    Du musst auch nicht zwingend etwas Ändern, es läuft ja grundsätzlich auch mit USB3 - bei mir gerade auf dem J5005. Also etwas mit den Parametern herumspielen.

    Vielleicht hilft auch, das autosuspend von usbcore abzuschalten : echo -1 > /sys/module/usbcore/parameters/autosuspend

    LG Helmut

    annst Du mal Deine Treiber Änderungen posten

    Ich sehes mir gleich an.

    Mit USB3 meinte ich mehr den xHCI Host Controller Treiber, dein USB2 Anschluß hängt sehr warscheinlich intern an einem USB3-Hub, verwendet also auch den xHCI Treiber. Bei "echtem" USB2 wird der EHCI Treiber verwendet - und damit läuft das WinTV-CI besser.

    LG Helmut

    Ich habe den Treiber damals auf und für ein Notebook mit USB2 und dem SimlpiTV Modul geschrieben. Das hat eigentlich recht stabil funktioniert, die Datenrate des/der Programme sollte aber mind. 2Mbit/s sein (warum weiss ich noch nicht) - aber, je höher desto besser.

    Mit USB3 sind dann Fehler wie du sie bemerkt hast, aufgetaucht.

    Zusätzlich verhält es sich mit jedem Modul etwas anders (auch bei USB2). Es gibt daher ein paar Treiberoptionen mit denen man sein Glück versuchen kann

    Die zwei wichtigsten - und wie ich sie mit den SimplTV Modul (SMIT) verwende:

    options wintv_usb2ci dummy_half_uframes=2 # 1,2 oder 3

    options wintv_usb2ci fx2_movx_stretch=6 # 3..7


    SMIT und SmarDTV sind leichter zum laufen zu bekommen, Neotion und Alphacrypt war bei mir eher schwierig.

    Und dann kann es noch am Mainboard/USB3 liegen. Am ASUS J5005-ITX geht es gefüht besser als z.B. mit einem Asrock J3455-ITX.

    Ich habe am Treiber noch ein paar Dinge ausprobiert, die ich aber nicht auf github geladen habe.

    Falls es bei dir gar nicht läuft kann ich mir die Änderungen genauer ansehen und ggf hier posten.

    LG Helmut

    Da habe ich beim Übernehmen des mcli-patch einen Fehler eingebaut. Durch diesen wurde in der ScrambleDetection mit InternalCAMs und TRANSFERPRIORITY das "IsScrambled"-Timeout nicht zu Ende geprüft (und ich habe es nur mit CamSlots getestet).

    Code: device.c - Diff. v.2 zu v.3
    1. if (Now - Receiver->startScrambleDetection > Receiver->scramblingTimeout) {
    2. - if ((cs && !cs->IsActivating()) || Receiver->Priority() >= LIVEPRIORITY) {
    3. + if (!cs || !cs->IsActivating() || Receiver->Priority() >= LIVEPRIORITY) {
    4. if (Receiver->ChannelID().Valid()) {

    Hier nun die Version 3, mit der die Scrambled-Erkennung und das Retune funktionieren sollte.

    cinfo - kannst du bei Gelegenheit noch einmal einen vdr-2.4.6 mit diesem Patch für BM2LTS bauen - Danke!

    LG Helmut

    Hier die Version 2 des vdr-mcli Patch und das Diff zum ersten vdr-mcli Patch.

    Es wird nun bei der ScrambleDetection das Timeout der 'TS_SCRAMBLING_TIME_OK' auf 35 Sekunden gesetzt. Damit sollte erkannt werden, wenn der Netceiver nach dem setzten der DVB Date/Time nicht mehr entschlüsselt und es kann das notwendige Retune durchgeführt werden. Diese Änderung findet man auch in den Sourcen von ReelVdr - es könnte also diesmal klappen,


    cinfo : kannst du noch einmal einen vdr-2.4.6 mit dem mcli2 Patch bauen - das wäre eine große Hilfe.

    gggggg : das mcli-0.9.6i Plugin sollte damit weiterhin funktionieren - als debugmask genügt dann 0xdf


    LG helmut

    So, hier die neue Variante 0.9.5i.

    Ich habe 3 Optionen konfigurierbar gemacht (die debugmask 0xdf immer dazunehmen):


    1) 0x400 - kein PAT/PMT Filter setzen des VDR - (0.9.5g) = 0x4df

    2) 0x800 - PMT-Pid für ORF1 oder ORF2O dauerhaft setzen - (0.9.5h) = 0x8df

    3) 0x2000 - Ein Delay von 100ms zwischen CloseFilter() und Openfilter() = 0x20df
    Die Bits können auch kombiniert werden (0xcdf, 0x28df, 0x24df, 0x2cdf).


    Starte die Tests mit 0x8df und 0x20df, und als Caid der vorerst immer "11" nehmen.

    LG Helmut