mcli ERROR: video data stream broken

  • Post by gggggg ().

    This post was deleted by the author themselves ().
  • HelmutB _orf2hd_0214h_reelAVG_3tun_CA11_noTxt_OK hochgeladen: S11/CA11, kein Teletext. Welchen Vergleich soll ich anstellen ?


    1 Vergleiche:

    Reel zu "Reel ohne txt" und "Reel ohne txt" zu NUC im Anhang...


    2 Der "PMT -> ERROR: parse_pmt_ca_desc() : CRC err. crc kommt nicht in allen NOK vor, jedoch ist klar dass in den NOK Fällen die erneute Anforderung

    mcg: ff18:3004:0:17c8:55f0:8022:70b4:6000 CAID = 13304

    fehlt.


    3 Bei den NUC logs, sind oft aber nicht immer ERROR: Meldungen im ncv log zu finden. Auch dieser ERROR: NO CA/ES descriptors avaiable for sid 13304 !


    4 Beim NUC geht es dann OK wenn keine ca_del_pid vorkommen.


    Analyse NUC _0214g

    5 Die Frage ist ob die " 09:59:12 BM2LTSNuc64native-MCLI vdr: ------- Mcli::recv_redirect(1) und folgende "Mcli::deallocate_slot" beim NCV schon den 1. Fehler zur Folge haben (od. umgek.):

    PMT -> ERROR: parse_pmt_ca_desc() : CRC err. crc = 0x2cc94b69


    6 nach 5 syslog "PID:1922,1921,1920..." und den 5 äquivalenten ncv Meldungen "MLD MCGs: 19 Subscribers: 19"

    kommt vom NCV "ca_del_pid: caid = 4911 pid 1920"

    und im syslog steht

    ------- Mcli::recv_redirect(1): mcg at ff18:3004:132f:17c8:55f0:8022:730c:6000, receiver 0x55b8b6ad7280 pid 0 id 4911

    aber keine erneute Anforderung.


    7 Bei der AVG_orf2hd_0214h_ folgt auf das manuell ausgelöste

    Feb 14 13:51:05 BM2LTSR66RBex vdr: [5121] switching to channel 2

    das 1. automatische

    Feb 14 13:51:12 BM2LTSR66RBex vdr: [5121] switching to channel 2

    und ein 2. bei den ca. 30s

    Feb 14 13:51:40 BM2LTSR66RBex vdr: [5121] switching to channel 2


    und im ncv log gibt es auch 2x ein ca_del_pid: caid = 13304 mit sofort nachfolgenden 3 PID Anforderungen

    mcg: ff18:3004:0:17c8:55f0:8022:70b4:6000 CAID = 13304 pid = 3002 red. sid 13304 PRIORITY 1 listener fe80::2e0:f4ff:fe17:b98c


    8 Löst mcli oder der vdr diese Anforderung aus .?

  • Hier der mcli-patch angepasst an den vdr-2.4.6.

    Grundsätzlich verhindert er ein Retune bei InternalCAMs wenn nur Caids oder caDescriptors hinzugefügt oder entfernt wurden da der VDR keinen Zugriff auf die CAMs hat und hier nichts tun kann (und muß). Außerdem wird die SrcambleDetection auch mit InternalCAMs aktiviert.

    gggggg : Ich werde versuchen, dir einen gepatchten vdr-2.4.6 für BM2LTS zu bauen. Dieser sollte sich dann so wie der vdr-1.7.xx des Reelvdr verhalten.

    LG Helmut

  • cinfo - Danke, das hat mir das Nachdenken über die richtige Make.config erspart :)

    Zur Sicherheit im Anhang noch das mcl-0.9.5f Plugin, gebaut gegen den gepatchten vdr-2.4.6-mcli.

    LG Helmut

    ok, habe ich in das Image übernommen


    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

  • Hi,


    sind denn die Patches für die MCLI-Version F schon GIT ?


    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

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

  • sind denn die Patches für die MCLI-Version F schon GIT ?

    bei mir kam noch kein Patch bzw. PR an...

  • Danke cinfo und HelmutB : VDR2.4.6_testB, mcli 095f


    Leider verhält es sich laut den soeben hochgeladenen logs _0215b_ sowohl bez. dem ERROR: als auch "ca_del_pid" völlig ident zu den bisherigen Versuchen und somit gilt meine Analyse zu 0214g:

    Wenn es cinfo möglich ist, wäre mein mit Helmut bespr. nächster Vorschlag mcli 0.95f für die Reel-AVG BM2LTSNUC2.94.4 mit reel-vdr 1.7.21.9 zu bauen.

    Dann sehen wir am ncv und sys-log was anders läuft.


    IMHO bin ich rel sicher, dass es mit den im Zitat Punkt 7 zu sehenden erneuten Anwählen des Kanals zu tun hat.

    Mir ist nur nicht klar ob der NCV über mcli091 den vdr1.7 anstößt oder mcli091/vdr1.7. das von sich aus machen.

    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 2 times, last by gggggg ().

  • Ich habe deine Logs auch noch einmal angesehen. Was auffällt ist, dass wenn die CAPMTs nicht erfolgreich geschrieben wrd, immer diese

    Slot 2: Can't get PMTs !

    oder diese

    ERROR: parse_pmt_ca_desc() : CRC err. crc = 0x2cc94b69

    Meldung vorangeht.


    Der VDR selbst schaltet in pat.c relativ oft über alle im Stream vorhandene PMT-Pids um, in der Vdr version 1.7.xx etwas anders als in 2.4.6, daher könnten die unterschiedlichen VDR-Versionen auch etwas ausmachen.


    Hier noch ein Test, bei dem die PMT-Pids für ORF1 und ORF2O von mcli-0.9.5h permanent aktiviert werden.

    LG Helmut

  • HelmutB so verhält es sich auch mit 095h und den logs 0216a. (Bitte nicht vergessen, dass das CAM erst später bereit ist. Ich schalte immer erst 5s nach der "bereit" auf orf). Gab es eig. in de mcli 091 auch schon debug Meldungen die man aktivieren konnte ?

    Liebe Grüße g ;-)

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

  • Das war leider nichts.

    Die PMT-Pid 107 wird zwar beim Start von ORF1 gleich mitaktiviert, nur habe ich übesehen, das es keine Referenzzähler gibt. DEshalb wird sie von pat.c beim Wechsel der PMT-Pids wie sonst auch wieder entfernt:

    Ich schicke dir am Abend eine neu Version.

    LG Helmut


    Edit: und dann wieder das übliche Slot 3: Can't get PMTs !

  • 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

  • HelmutB 095i, 0217a=08df, 0217b=20df, hochgeladen ... im Endergebnis leider keine Änderung

    0217a:

    ERROR: NO CA/ES descriptors avaiable for sid 4911 !

    den hatten wir auch schon früher. Und den üblichen

    PMT -> ERROR: parse_pmt_ca_desc() : CRC err. crc = 0x7795ddcd


    0217b:

    PMT -> ERROR: parse_pmt_ca_desc() : CRC err. crc = 0xa843af0e

    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 3 times, last by gggggg ().

  • 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

  • HelmutB Danke aber leider NEIN, Logs 0220a (gleicher Ort): NUC&NCV fahren gemeinsam hoch, mcli 095i, vdr_210220c, vPID19200, CA11, debugDF


    Freeze ca. 20s. nach KEY. Ich habe dann noch ca. 10s gewartet bevor ich die Files kopiert habe.

    Feb 20 10:41:15 BM2LTSNuc64native-MCLI irexec[1656]: KEY_1

    Feb 20 10:41:17 BM2LTSNuc64native-MCLI vdr: [1603] switching to channel 1 S19.2E-1-1007-4911 (ORF1 HD)


    hier dann die vPid Änderung

    Feb 20 10:41:21 BM2LTSNuc64native-MCLI vdr: [1613] changing pids of channel 1 (ORF1 HD) from 19200+19200=27:0;1921=deu@106,1922=mis@106:0:1925 to 1920+1920=27:0;1921=deu@106,1922=mis@106:0:1925

    Feb 20 10:41:21 BM2LTSNuc64native-MCLI vdr: [1603] switching to channel 1 S19.2E-1-1007-4911 (ORF1 HD)


    und kein 3. switching ... auch das ncv log eig. so wie gestern.


    Edit: Ich hab dann noch einen Test mit korrekter vPid gemacht: da war kein 2. switching und nach ca. 40s Schluss: logs 0220b

    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 11 times, last by gggggg ().

  • 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

  • cinfo , HelmutB , Danke euch ... mein 1. Versuch schaut gut aus: logs sind am gleichen Ort mit Folgendem Namen: NUCuNCVboot095iD_orf1hd_0220c_nuc_2tun_upd3_CA11_df_Vpid_OK mit 3 switchings ;-) ich teste mal ohne CA11 und mit korrekter vPID weiter ...

    Ohne manipulierter vPID aber mit CA11 auch OK: 0220d ORF1 HD;ORF:11303:HC23M5O35P0S1:S19.2E:22000:1920=27:0;1921=deu@106,1922=mis@106:1925:11:4911:1:1007:0

    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 4 times, last by gggggg ().