mcli ERROR: video data stream broken

  • ad b) als option beim Aufruf ... sonst default 45. Was ist der Nachteil ? CPU Last od. ???

    Liebe Grüße g ;-)

    BM2LTS V2.94.4, ext.NCV+AlphacryptCAM+ORFkarte, AVG1 T7400 RAM4GB SSD+HDD2TB NvidiaGT720, NCL2 mit HDD

    The post was edited 1 time, last by gggggg ().

  • Post by gggggg ().

    This post was deleted by the author themselves ().
  • Guten Morgen HelmutB : 2021-02-21.09.11.1-0.rec am gleichen Ort. Im rec. directory liegen auch die logs.

    Der Stream wurde unterbrochen und geteilt. Ist also leider NOK, aber die Meldung "ERROR: video data stream broken" und der Notausstieg des vdr unterbleibt.

    1 Ev. ist das Problem, dass das Anwählen 1 min. vor Aufnahme keine Reaktion generiert. Es sind danach keine orf PIDs gesetzt.

    2 Warum braucht es dann noch 4 weitere Anläufe.... Bei Live kommen wir mit max. 2 aus.

    3 Beim ncv läuft da was gewaltig schief. Bis es sich stabilisiert ist das log voll mit ts2psi_data:No sync byte in header !


    Startkanal: Feb 21 09:09:59 BM2LTSNuc64native-MCLI vdr: [1757] switching to channel 17 S19.2E-133-5-776 (SIXX)

    1min v. Rec: Feb 21 09:10:10 BM2LTSNuc64native-MCLI vdr: [1757] switching device 2 to channel 1 S19.2E-1-1007-4911 (ORF1 HD)

    Das Anwählen setzt aber keine orf PIDs ...

    Rec: Feb 21 09:11:00 BM2LTSNuc64native-MCLI vdr: [1757] switching device 2 to channel 1 S19.2E-1-1007-4911 (ORF1 HD)

    Feb 21 09:11:08 BM2LTSNuc64native-MCLI vdr: [1757] switching device 2 to channel 1 S19.2E-1-1007-4911 (ORF1 HD)

    Feb 21 09:11:12 BM2LTSNuc64native-MCLI vdr: [1757] switching device 2 to channel 1 S19.2E-1-1007-4911 (ORF1 HD)

    Feb 21 09:11:30 BM2LTSNuc64native-MCLI vdr: [1757] switching device 2 to channel 1 S19.2E-1-1007-4911 (ORF1 HD)

    Ich habe dann nach Ende des rec. um 9:13 noch manuell auf ORF1 geschaltet ... alles OK .. 30s gewartet und die logs kopiert.


    Brauchst du für weitere Tests die .ts recordings oder kann ich mir das Hochladen dieser sparen ?

    Liebe Grüße g ;-)

    BM2LTS V2.94.4, ext.NCV+AlphacryptCAM+ORFkarte, AVG1 T7400 RAM4GB SSD+HDD2TB NvidiaGT720, NCL2 mit HDD

    The post was edited 1 time, last by gggggg ().

  • Post by gggggg ().

    This post was deleted by the author themselves ().
  • HelmutB Ich habe den Test auch an der AVG gemacht:

    1 Starte ich die AVG erst kurz vor der Aufnahme, sodass sie keine Zeit mehr hat 1 min. vorher umzuschalten, kommt es während der ersten 30s zum erneuten switching und die .ts werden geteilt. Allerdings in Summe nur 2 switchings und keine ncv errors !


    2 Starte ich früh genug wie in den soeben hochgeladenen logs _NCVuNCVbootDMAX_orf1hd_0221a_reelAVG_ wählt sie auch 1 min. vorher den orf2HD an und es kommt während dieser 1 min. zu 2 zus. switchings bevor sie den Kanal zur Aufnahme 11:43 final anwählt und kein zus. switching = keine .ts Teilung entsteht.


    3 Ich habe noch AVG Beispiele

    0221b: Mit "ts2psi_data:No sync byte in header !" allerdings ohne .ts Teilung

    0221c: 5s nach Aufnahmestart ein switching, dass auch zu keiner .ts Teilung führt

    Liebe Grüße g ;-)

    BM2LTS V2.94.4, ext.NCV+AlphacryptCAM+ORFkarte, AVG1 T7400 RAM4GB SSD+HDD2TB NvidiaGT720, NCL2 mit HDD

    The post was edited 1 time, last by gggggg ().

  • Hier noch Testaufnahmen vom NUC:

    2021-02-21.13.48.1-0.rec: Geteilter .ts weil switching 15s nach Aufnahmestart ohne die vielen ncv errors


    Resümee zu 0221a:

    Warum es zu den ts2psi_data Fehlern kommt ist unklar, aber auch auf der AVG. Sie enden denke ich mit dem Senden der Zeit an das CAM

    Liebe Grüße g ;-)

    BM2LTS V2.94.4, ext.NCV+AlphacryptCAM+ORFkarte, AVG1 T7400 RAM4GB SSD+HDD2TB NvidiaGT720, NCL2 mit HDD

    The post was edited 7 times, last by gggggg ().

  • 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 einfachst wäre doch beim NUC eine Verzögerung vor Start des vdr einzubauen ... da würden doch 10-15s reichen ... wo wäre der beste Ort ?

    Liebe Grüße g ;-)

    BM2LTS V2.94.4, ext.NCV+AlphacryptCAM+ORFkarte, AVG1 T7400 RAM4GB SSD+HDD2TB NvidiaGT720, NCL2 mit HDD

    The post was edited 1 time, last by gggggg ().

  • Quote

    Das einfachst wäre doch beim NUC eine Verzögerung vor Start des vdr einzubauen ... da würden doch 10-15s reichen ... wo wäre der beste Ort ?

    das wäre leicht


    einfach in den Service /lib/systemd/system/networking.service und hier ändern


    Code
    1. [Service]
    2. Type=oneshot
    3. EnvironmentFile=-/etc/default/networking
    4. ExecStart=/sbin/ifup -a --read-environment
    5. ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
    6. RemainAfterExit=true
    7. - TimeoutStartSec=15sec
    8. + TimeoutStartSec=32sec

    cinfo

    (VDR) NUC10i3FNK * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Player) LG UP970 * (Stream) Apple TV 4K * (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65GX9LA

  • 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

  • HelmutB Danke für die Analyse...


    1 Bringt denn das Anwählen des 1. Kanals (orf1HD) auch was für eine Aufnahme auf ORF2 (weil anderer Transponder) ... geht es also nur drum das CAM 1x genutzt zu haben ?


    2 Aber der reelvdr hat da in der 1. Min. vor Aunahme einige switchings produziert in einem der Reel Beispiele ...


    3 Könnte ich das Anwählen auch per SVDRP SCAN ev. per rc.local machen ?

    Ich habe bei der AVG seit Jahren Folgendes eingebaut:


    Code
    1. ...
    2. /usr/bin/logger -t ri_rc "rc start und wait"
    3. sleep 45 #r warten bis vdr hochgefahren min. 35s
    4. /usr/bin/logger -t ri_rc "rc EPG update"
    5. /usr/sbin/svdrpsend.sh SCAN
    6. sleep 180 #r vorausgesetzt 6 min vorher geweckt
    7. # sudo hdparm -y /dev/sda
    8. /usr/bin/logger -t ri_rc "rc timer update"
    9. /usr/sbin/svdrpsend.sh PLUG epgsearch UPDS

    Liebe Grüße g ;-)

    BM2LTS V2.94.4, ext.NCV+AlphacryptCAM+ORFkarte, AVG1 T7400 RAM4GB SSD+HDD2TB NvidiaGT720, NCL2 mit HDD

  • 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

  • Danke HelmutB , Test Aufnahme orf2 mit 095j und vdr D, debug 40df, Ablage wie immer

    ORF2O HD;ORF:11273:hC23M5O35S1:S19.2E:22000:3000=27:0;3001=deu@106,3002=mis@106:3005:D98,650,D95,648,6E2,98C,9C4,98D,500:13304:1:1005:0


    NUCuNCVboot095jD_orf2hd_0223a_: hier waren auch 35s Verzögerung eingebaut und viele Plugins (teletext, epg,...) aktiv, Meldung CAM-Triggerim log

    Feb 23 17:14:40 BM2LTSNuc64native-MCLI vdr: [1710] switching to channel 17 S19.2E-133-5-776 (SIXX)

    Feb 23 17:14:40 BM2LTSNuc64native-MCLI vdr: [1710] Mcli::SetPid: FTA CAM-Trigger Pid 767 Sid 776

    Feb 23 17:14:40 BM2LTSNuc64native-MCLI vdr: [1710] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD)

    Feb 23 17:14:40 BM2LTSNuc64native-MCLI vdr: [1710] info: 'AlphaCrypt'-Modul bereit

    Aufnahmestart: Dauer 2min

    Feb 23 17:15:00 BM2LTSNuc64native-MCLI vdr: [1710] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD)


    _0223b_: ohne Plugins, mit den bisherigen 15s, nur 1 min vor Aufnahme gestartet, kein CAM-Trigger im log

    Feb 23 17:50:29 BM2LTSNuc64native-MCLI vdr: [1770] switching to channel 17 S19.2E-133-5-776 (SIXX)

    Feb 23 17:50:29 BM2LTSNuc64native-MCLI vdr: [1770] Mcli::CAMAlloc: AllocateCAM [(null)]:0 -> FAIL

    Feb 23 17:50:29 BM2LTSNuc64native-MCLI vdr: [1770] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD)

    Feb 23 17:50:29 BM2LTSNuc64native-MCLI vdr: [1770] Mcli::CAMAlloc: AllocateCAM [(null)]:-1 -> FAIL

    Feb 23 17:50:34 BM2LTSNuc64native-MCLI vdr: [1770] info: 'AlphaCrypt'-Modul bereit

    Aufnahmestart: Dauer 2min

    Feb 23 17:51:00 BM2LTSNuc64native-MCLI vdr: [1770] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD)


    _0223c_: ohne Plugins, mit den bisherigen 15s, 3 min vor Aufnahme gestartet, kein CAM-Trigger im log

    Feb 23 18:07:15 BM2LTSNuc64native-MCLI vdr: [1593] switching to channel 17 S19.2E-133-5-776 (SIXX)

    Feb 23 18:07:15 BM2LTSNuc64native-MCLI vdr: [1593] Mcli::CAMAlloc: AllocateCAM [(null)]:0 -> FAIL

    Feb 23 18:07:19 BM2LTSNuc64native-MCLI vdr: [1593] info: 'AlphaCrypt'-Modul bereit

    Feb 23 18:08:10 BM2LTSNuc64native-MCLI vdr: [1593] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD)

    Aufnahmestart: Dauer 2min

    Feb 23 18:09:00 BM2LTSNuc64native-MCLI vdr: [1593] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD)

    Feb 23 18:09:38 BM2LTSNuc64native-MCLI vdr: [1593] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD)



    das hab ich im _0223a_ log gesehen während ich die Aufnahmetimer für den Test auf ORF2 erstellt habe ... gehts da um Timer oder um ?

    Liebe Grüße g ;-)

    BM2LTS V2.94.4, ext.NCV+AlphacryptCAM+ORFkarte, AVG1 T7400 RAM4GB SSD+HDD2TB NvidiaGT720, NCL2 mit HDD

    The post was edited 1 time, last by gggggg ().

  • 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.

  • @HelmutB

    wäre es möglich einmal einen Patch gegen den Git-Stand von pbrb zu erstellen.

    Dann könnte man z.B. das MCLI-Plugin dort auf den Stand 0.96 heben.


    Grüße

    cinfo

    (VDR) NUC10i3FNK * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Player) LG UP970 * (Stream) Apple TV 4K * (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65GX9LA

  • Hier wäre der TriggerCam-Patch gegen das aktuell Git von pbrb .

    Als debugmask habe ich dafür #define DEBUG_BIT_Action_TriggerCam 0x4000definiert.


    Es ist die einzige Funktion, die ich aus dem mcli-0.9.5j.patch genommen habe, die anderen Dinge haben sich als nicht notwendig oder zielführend erwiesen, und die Option DEBUG_BIT_Action_NoRetuneFirstTuner ist im Git schon enthalten.

    Sie hat aber einen irreführenden Namen, da bei gesetztem Bit das (Re)tune doch ausgeführt wird. Da das aber meiner Meinung nach sowieso nicht per default vom plugin gemacht werden sollte, wäre ein Bezeichnung wieDEBUG_BIT_Action_RetuneOnFirstTuner richtiger und auch zum aktuellen Verhalten passend.

    Und beiDEBUB_BIT_recv_ts_func_NO_LOGRATELIMITgibts einen typo. Die beiden Dinge hätte ich noch in ein Diff gepackt.

    LG Helmut

  • Danke für die Patches, "master" aktualisiert (noch paar Typos gefixt). Wie soll es nun mit dem Retune sein? Braucht's da eine Option (Commandline oder Setup) für das Verhalten?

  • Post by gggggg ().

    This post was deleted by the author themselves ().