[gelöst] mcli ERROR: video data stream broken

  • HelmutB ohne CA11 und ohne Vpid leider ein freeze : 0220e ... ev. stimmt die channels nicht

    channels:

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


    nur das manuelle switching

    Feb 20 19:01:59 BM2LTSNuc64native-MCLI vdr: [1553] switching to channel 1 S19.2E-1007-0-1 (ORF1 HD)


    Der Kanal brachte von Beginn an kein Bild ! Auch im ncv log kein ca_del_pid abr dafür CAID=1

    mcg: ff18:3004:0:17c8:55f0:8022:730c:6000 CAID = 1 pid = 1922 red. sid 1 PRIORITY 0 listener fe80::1e69:7aff:fe6a:6656


    ich nehme nun diese channels:

    ORF1 HD;ORF:11302:hC23M5O35S1:S19.2E:22000:1920=27:0;1921=deu@106,1922=mis@106:1925:648,650,D95,D98,6E2,500,98D,9C4,98C:4911:1:1007:0

    damit ist es OK: 0220f

    2 switchings, das 2. nach über 30s.

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    6 Mal editiert, zuletzt von gggggg ()

  • 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

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

  • Helmut du bist unser Hero und herzlichen Dank auch an cinfo ! Wenn wir geimpft sind, besuchen wir sicher wieder mal in deine Heimatstadt ...


    Ich werde es heute meiner besseren Hälfte zum Test übergeben ...


    Auch damit ist es OK: 0220g


    a) Helmut werden die 30s nach jedem Versuch zu entschlüsseln (also ohne kanalwechsel = keine manuellen Eingriffe) zurück gesetzt ?


    b) Von der AVG weis ich dass es manchmal bis über 40s dauern kann bis es stabil läuft .. daher die Frage ob diese Zeit nicht einstellbar sein sollte bzw. 35 zu wenig sind ?


    Ich werde dann morgen noch mit osdteletext ... testen

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    2 Mal editiert, zuletzt von gggggg ()

  • 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

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

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

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    Einmal editiert, zuletzt von gggggg ()

  • Nutzlast sicher nicht viel, außerdem nur für ein paar Sekunden.

    Das Retune bei Live funktioniert offensichtlcih, aber wie sieht es bei Timeraufnahmen mit Wakeup aus - das war ja das Hauptproblem.

    LG Helmut

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

  • 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 ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    Einmal editiert, zuletzt von gggggg ()

  • 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 ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    Einmal editiert, zuletzt von 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 ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    7 Mal editiert, zuletzt von 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
                                                                       aktuelle Systemzeit NCV: 61 Sekunden |
    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
    Start Streaming PID 0 Tuner on slot 0 count 0 MCG ff18:3004:0:17c8:55f0:8022:72f8:6000, satpos 1992
          == 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

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

  • 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 ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    Einmal editiert, zuletzt von gggggg ()

  • Zitat

    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
    [Service]
    Type=oneshot
    EnvironmentFile=-/etc/default/networking
    ExecStart=/sbin/ifup -a --read-environment
    ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
    RemainAfterExit=true
    - TimeoutStartSec=15sec
    + TimeoutStartSec=32sec

    cinfo

    (VDR) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA

  • 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 passed unfortunately away on July 21, 2022 ... RIP 🖤

  • 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
    ...
    /usr/bin/logger -t ri_rc "rc start und wait"
    sleep 45   #r warten bis vdr hochgefahren min. 35s
    /usr/bin/logger -t ri_rc "rc EPG update"
    /usr/sbin/svdrpsend.sh SCAN
    sleep 180    #r vorausgesetzt 6 min vorher geweckt
    # sudo hdparm -y /dev/sda
    /usr/bin/logger -t ri_rc "rc timer update"
    /usr/sbin/svdrpsend.sh PLUG epgsearch UPDS

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

  • 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 ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    Einmal editiert, zuletzt von 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 passed unfortunately away on July 21, 2022 ... RIP 🖤

  • @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) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA

  • 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

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!