Posts by HelmutB

    Ich habe leider mit der TriggerCam Option auch einen Fehler eingebaut - deshalb bei den Test f,g und h kein Bild.

    Im Anhang die Version 0.9.5n die diesen Fehler korrigiert.

    MTD - habe ich auch gesehen - a,b,c mit MTD, der Rest mit MCD.


    pbrb : Der Patch ist für dein mcli auf Github.

    Wenn man dann auf einen dieser Kanäle schaltet, dann ändern sich die Transponder-Einstellungen:

    Das habe ich auch schon einmal bei anderen (französischen) Programmen gesehen. Es wird vermutlich so sein:


    1) Entweder gibt es noch veraltetet Programm in der channels.conf für diesen Transponder oder die neuen Programme sind noch nicht auf allen Transpondern aktualisiert und es werden in den NITs auch noch die alten Transponderparameter übertragen. Nur das erste Vorkommen eines Transponders landet in der Scanlist des EITscanners, und damit u.U die mit den veralteten Parametern.


    2) Das DVB-Device verwendet zum Tunen nur Frequenz und Symbolrate. Bei manchen DVB-Treibern werden die Transponderparameter gar nicht berücksichtigt sondern es wird eine Art Autoscan/Autotune durchgeführt - wie z.B bei meiner DvbSky S950, möglicherweise auch von der Cine S2. Dadurch kann beim EITscan auch mit den falschen Parametern getuned werden und in sdt.c werden neue Programme dann auch mit diesen Transponderparametern angelegt.

    Erst beim 2. Tunen auf diesen Transponder werden in nit.c die Parameter aus den Angaben der eigenen NIT (sozusagen für sich selbst) modifiziert - beim 1.Tunen (beim Eitscan) sind diese Programme ja noch nicht in der Channels Liste da die SDT erst nach der NIT ausgewertet wird.


    LG Helmut

    pbrb : Ich hätte aus dem mcli-patch für gggggg schon Teile, deren Übernahme vielleicht sinnvoll ist:

    01-TriggerCamAllPids.patchEs werden beim CamTrigger alle FTA Audio und Video Pakete durch das CAM geleitet, da sonst Bild und Ton asynchron werden.

    02-DeviceReadyWithCi.patchDas (Device)Ready wartet bis alle CAM- Resets im Netceiver abgeschlossen sind. D.h. der VDR Start muß nicht extra verzögert werden.

    04-TriggerCamByDefault.patch Optional: setzt 'DEBUG_BIT_Action_TriggerCam' in m_debugmask als default - wie im obgen Post beschrieben.

    Ich habe sie gegen deinem heutigen Stand auf github getestet, sollten also passen. Schau sie dir einmal an.

    LG Helmut

    gggggg : hier die Version mcli-0.9.5m bei der 0x4000 per default aktiviert ist - wenn du allerdings dem Plugin eine 'debugmask' Option mitgibst, musst du 0x4000 wieder explizit anführen.


    Um dei ScramblingDetection Zeit zu erhöhen muss im vdr-mcli4.patch nur diese Zeile angepasst werden

    +#define TS_SCRAMBLING_TIME_OK 35 // seconds before a Channel/CAM combination is marked as known to decrypt

    Mein Binary für VDR wird bei BM2LTS vermutlich nicht richtig laufen, vielleicht hat cinfo einmal Zeit und Lust, dir eine angepasste Version zu bauen.


    Diese lange ScramblingDetection ist meiner Meinung nach auch nicht wegen dem Netceiver erforderlich. Es hat vielmehr mit den besonderen Eigenschaften der Alphacrypt zu tun - ein Standard-Modul wird sehr wahrscheinlich überhaupt nicht zu Entschlüsseln beginnen wenn die auf der Smartcard hinterlegten Berechtigungen 50 Jahre in der Zukunft liegen sondern erst nach Einlangen des richtigen Datums. Mit Standard-CAMs wäre dann vemutlich das 'TS_SCRAMBLING_TIMEOUT' anzupassen um nicht zu viele Retunes in zu kurzen Anständen zu erhalten.

    LG Helmut

    D hast recht - 18. == 0x12 ist die EIT-Pid. Jede Section hat einen 3 Byte Header - 1. Byte = Table-Id, 2+3Byte (nur 12 Bit) die Länge der nachfolgenden Daten. Deshalb das Maximum vom 4093+3=4096 Bytes.

    Bei dir sind aber die ersten 3. Bytes alle 0xFF (4095. == 0xFFF) und wahrscheinlich der Rest auch. Da sind normalerweise die Füllbytes nach der Section (Len) bis zum Ende eines 188 Byte TS-Pakets. Also stimmt irgendetwas mit dem Buffer nicht. Auch wenn du 8192 Byte liest, werden die Daten trotzdem nicht richtiger sein.


    Siehst du im Log irgenwo eine Fehlermeldung mit 'DMX_SET_BUFFER_LEN", bzw. ist das nur bei diesem Transponder ("NHK World")?

    LG Helmut

    Die ScrambleDetection im VDR hat die Funktion sich bei mehreren CAMs im System eine funktionierende Programm/Camslot Kombination zu merken und beim nächsten mal bevorzugt zu verwenden. Sie ist nicht dazu gedacht Fehler zu beheben und wird mit nur einem Modul und ohne mcli-Patch überhaupt nicht aktiviert.


    Sie beginnt mehr oder weniger unmittelbar nach SwitchChannel und dann bei jedem Wechsel von scrambled <-> descrambled.

    #define TS_SCRAMBLING_TIMEOUT 3 // seconds to wait until a TS becomes unscrambled (--srctmo)

    #define TS_SCRAMBLING_TIME_OK 35 // seconds before a Channel/CAM combination is marked as known to decrypt (--descrtmo) (ungepatcht sind es 3s/3s)
    Nach 3s 'verschlüsselt' kommt bei Dir das Retune, nach 35s 'entschlüsselt' wird die ScrambleDetection beendet, nachfolgende Fehler im Netceiver werden nicht mehr erkannt. Die ScrambleDetection kannst du bei 64bit 'fast' auf unendlich einstellen, 3600 ist eine Stunde, 86400 24 Stunden, usw. Die Nachteile dieser Prüfung sind auf deinem NUC sicher vernachlässigbar, kürzer wäre natürlich immer besser.

    LG Helmut

    Bei den Versuchen 306e und 306h hat der Netceiver massive Empfangsprobleme.

    ts2psi_data:No sync byte in header !

    get_tdt_sect:FIXME:TIMEOUT for pid TDT slot 0 ! Possible relaibility issue !


    In 0603h wird Date/Time erst nach dem Beenden der scrambleDetection gefunden, daher auch kein Retune mehr.
    Du kannst natürlich die DeScrambleDetection Zeit auf einen viel größeren Wert setzen, besser wäre es aber, herauszufinden warum es diese Signalprobleme gibt.

    Entferne durch einmal 2 deiner 3 Tunerkarten und teste immer mit nur eine Karte. Es müssen alle Versuche das gleiche Ergebnis liefern.

    LG Helmut

    Mär 05 08:13:40 server01 vdr[8439]: [8445] tp 211229 (18/FF) read incomplete section - len = 4098, r = 4096

    Das deuted im Zusammenhang mit deinem 386er auf einen zu kleinen Buffer für die EIT-Section hin. Du kannst den Buffer mit dem Patch im Anhang vergrößern.

    Obwohl du vermutlich leichte Signalprobleme hast, sollten alle SDT und EIT Sections die im VDR ankommen trotzdem fehlerfrei sein, da sie vorher vom dvb-core Linux-Treiber geprüft werden.

    Mär 05 08:14:09 server01 vdr[8439]: [8445] SDT: channel 62 NID/TID (1/1010) not found, got 1/1006

    Da du kein Unicable oder sonstige diseqc Kommandos verwendest, können das nur alte Daten des zuvor getunten Transponder sein - das habe ich bei mir auch schon bei PAT und SDT bemerkt.

    Im Sectionhandler::Action() sollten zwar solche alten Daten verworfen werden, da ist aber meiner Meinung nach ein Logikfehler bei einer Prüfung mit !DeviceHasLockenthalten.

    Ich habe diesen Teil für mich etwas abgeändert und es werden jetzt erst 200ms nach einem SetStatus(true) die Daten an die Filter weitergegeben.

    Du kannst ja diesen 2. Patch ja auch testen, vielleicht liegt es daran.

    Helmut

    Ich habe mir fast gedacht, dass man mit der PAT-Pid 0 keinen CAPMT erzwingen kann, diese Option hat deshalb überhaupt keinen Effekt.

    Das gilt für 0x8000 und auch für dir Kombination mit 0x4000. Ich habe daher die Option FORCE_CAM_PID0 in mcli-0.9.5m wieder entfernt.

    In dieser Version ist nun auch NOTIFY_CAM_CHANGE deaktiviert - die OSD Nachricht "AC-Modul bereit" wird damit nicht mehr angezeigt.


    Soweit man in den ncv-Logs sieht, fehlt dem netceiver manchmal der Ca-Descriptor für das aktuelle Programm, auch wenn er zuvor schon bekannt war und erfolgreich verwendet wurde. Das stört dann besonders, wenn das CA-Modul bei einer Timeraufnahme zum ersten Mal in Verwendung ist und diese Situaton durch das Setzten von Date/Time erst nach 30s auftritt.

    Da man von außen aber keinen Einfluss auf das CAM-Handling hat, hilft nur ein Retune durch die ScrambleDetection - und eine frühere CAM-Verwendung durch FORCE_CAM/0x4000.

    Wenn es damit aber zu mehreren Retunes kommt, ist vielleicht die scrambleDetectionTime zu kurz. Deshalb auch hier noch ein neuer Patch für den VDR, mit dem diese Zeiten angepasst werden können:

    Ich habe dabei die scrambleDetection auch leicht abgeändert. Im Anhang die Patches und Binaries - ich hoffe, du kannst sie verwenden.

    LG Helmut

    Hier die Version 0.9.5l: Mit 0x4000 (TriggerCam) nehmen nun alle FTA Audio und Video Pakete den gleichen Weg durch das CAM, Bild und Ton sollten damit wieder synchron sein.

    Eine neue - und vielleicht bessere - Variante ist es, nur die Dummy-Pid0 für das Triggern der CAM zu nehmen. Dazu gibt es das Flag 0x8000. Ich bin aber nicht sicher, ob der Netceiver für die PAT-Pid eine CAPMT an das CAM sendet und so das Update von Date/Time initiert.

    Ich hoffe ich habe die Idee im Patch richtig umgesetzt.


    Das eigenständige Tunen vom mcli-Plugin auf Kanal 1 mit Verzögerung muß ich mir erst ansehen. Ich finde es grundsätzlcih nicht besonders sinnvoll, andererseits hat es aber jemand (mit Netceiver) hineingeschrieben - also wird es auch einen Grund dafür gegeben haben.

    LG Helmut

    Die neue BM2LTS Installation sieht ja schon besser aus.

    Bei 228k und 228l ist der Netceiver durchgelaufen, daher wurden vom VDR die Camslots und Tuner auch ohne Startverzögerung sofort erkannt. Das neue Verhalten von 'mcli::Ready()' sieht man erst, wenn NUC und NCV gleichzeitig gestartet werden.


    Das mit dem Hall beim Flag 0x4000 kann ich mir ncht erklären da nur bei der Video-Pid eine Verschlüsselung vorgetäuscht wird.

    Gleichfalls beim Ton ohne Bild - ich sehe im NCV-Log beim Tunen ein "TIMEOUT FOR FREQ !!!" - vielleicht werden dann die Demux-Filter im NCV nicht richtig geöffnet - der VDR hat aber keinen Einfluss darauf.


    Teste die Version 095k mit Timer und gleichzeitigem Start von NCV und NUC - mit und ohne Flag 0x4000.

    LG Helmut

    Zu deine Fragen:

    1) der FTA CAM-Trigger fehlt bei i+j weil s beim tunen auf SIXX noch kein CAM gibt (vor "found CAM")

    2) der Freeze kommt vom Datenmüll (Tuner/Signal ?). Hat aber nichts mit der Entschlüsselung zu tun, da auch unverschlüsselete Pakete mit 0x47 im 1. Byte beginnen.

    3) kann ich schon machen, das wird aber ein VDR-Patch


    Ein weiter Test mcli-0.9.5k im Anhang: Ich habe das mcli::Ready() so abgeändert, dass WaitForAllDevicesReady() im VDR auf "found CAM" und "Alphacrypt Modul bereit" wartet. (max. aber nur 30s - ist so im VDR "Hart" definiert).

    Versuche es einmal damit.


    LG Helmut

    Ich glaube, der "richtige" Weg ist eine Startverzögerung beim VDR, nicht beim Netzwerk.

    Man erkennt in 0227e+f, dass dann sofort nach dem vdr-Start die Tuner und auch die beiden Camslots des Netceiver sichtbar sind.

    Das ist bei 0227i+j nicht der Fall. Da werden zuerst nur die Tuner sichtbar, die beiden Camslots und "found CAM" erst nach dem Tunen auf SIXX, und die "Alphacrypt bereit" Meldung (nach erfolgreichem CAM-Reset) noch einmal 5s später.

    Ob man das "Dummy" Pid0 ein- oder ausschaltet wird hier keinen Unterschied ausmachen.


    Bei dir gibt es beim Boot doch einige Warnungen wegen Pfad- oder Zugriffsfehler - z.B. Plexmedia. Wäre es nicht besser, diese nicht funktionierenden Dienste ganz zu deaktivieren (oder zu reparieren)?

    LG Helmut

    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