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

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

  • mcli 095j vdr D, debug x41df und 35s statt 15s Netzwerk = vdr Verzögerung, Aufnahmedauer immer 2min auf ORF2HD O. Die logs wie immer hier...


    _0226a_: vdr start 10s vor Aufnahme

    Feb 26 15:52:58 BM2LTSNuc64native-MCLI vdr: [1558] switching to channel 17 S19.2E-133-5-776 (SIXX)

    Feb 26 15:52:58 BM2LTSNuc64native-MCLI vdr: [1558] Mcli::CAMAlloc: AllocateCAM [(null)]:0 -> FAIL

    Feb 26 15:52:58 BM2LTSNuc64native-MCLI vdr: [1558] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD)

    Feb 26 15:52:58 BM2LTSNuc64native-MCLI vdr: [1558] Mcli::CAMAlloc: AllocateCAM [(null)]:-1 -> FAIL

    Feb 26 15:52:59 BM2LTSNuc64native-MCLI vdr: [1575] Found CAM 0

    timer start

    Feb 26 15:53:00 BM2LTSNuc64native-MCLI vdr: [1558] Mcli::CAMAlloc: AllocateCAM [(null)]:-1 -> [fe80::208:54ff:fe54:b261]:0

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


    _0226b_: vdr start 30s vor Aufnahme, 2 .ts streams, das recording dazu ist 2021-02-26.16.28.2-0.rec

    Feb 26 16:27:27 BM2LTSNuc64native-MCLI vdr: [1562] switching to channel 17 S19.2E-133-5-776 (SIXX)

    Feb 26 16:27:27 BM2LTSNuc64native-MCLI vdr: [1562] Mcli::CAMAlloc: AllocateCAM [(null)]:0 -> FAIL

    Feb 26 16:27:27 BM2LTSNuc64native-MCLI vdr: [1562] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD)

    Feb 26 16:27:27 BM2LTSNuc64native-MCLI vdr: [1562] Mcli::CAMAlloc: AllocateCAM [(null)]:-1 -> FAIL

    Feb 26 16:27:28 BM2LTSNuc64native-MCLI vdr: [1579] Found CAM 0

    Feb 26 16:27:38 BM2LTSNuc64native-MCLI vdr: [1562] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD)

    Feb 26 16:27:38 BM2LTSNuc64native-MCLI vdr: [1562] Mcli::CAMAlloc: AllocateCAM [(null)]:-1 -> [fe80::208:54ff:fe54:b261]:0

    Feb 26 16:27:49 BM2LTSNuc64native-MCLI vdr: [1562] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD)

    timer start

    Feb 26 16:28:00 BM2LTSNuc64native-MCLI vdr: [1562] Mcli::CAMAvailable: Available CAM [(null)]:-1 -> [fe80::208:54ff:fe54:b261]:0

    Feb 26 16:28:00 BM2LTSNuc64native-MCLI vdr: [1562] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD)

    Feb 26 16:28:11 BM2LTSNuc64native-MCLI vdr: [1680] Mcli::GetTSPacket: skipped 188 bytes to sync on TS packet on DVB 1

    ....

    Feb 26 16:28:11 BM2LTSNuc64native-MCLI vdr: [1680] Mcli::GetTSPacket: skipped 188 bytes to sync on TS packet on DVB 1

    Feb 26 16:28:12 BM2LTSNuc64native-MCLI vdr: [1680] CAM 0: won't decrypt channel S19.2E-1-1005-13304, detaching receiver  

    Feb 26 16:28:13 BM2LTSNuc64native-MCLI vdr: [1679] recording thread ended (pid=1562, tid=1679)

    Feb 26 16:28:13 BM2LTSNuc64native-MCLI vdr: [1562] timer 2 (2 1628-1630 'Lokalausstieg Oberösterreich') stop 

    Feb 26 16:28:13 BM2LTSNuc64native-MCLI vdr: [1562] removing /media/hd/recordings/Lokalausstieg_Oberösterreich/2021-02-26.16.28.2-0.rec/.timer 

    Feb 26 16:28:13 BM2LTSNuc64native-MCLI vdr: [1562] executing '/media/hd/recordings after "/media/hd/recordings/Lokalausstieg_Oberösterreich/2021-02-26.16.28.2-0.rec"' 

    Feb 26 16:28:13 BM2LTSNuc64native-MCLI vdr: [1562] Mcli::CAMAvailable: Available CAM [(null)]:-1 -> [fe80::208:54ff:fe54:b261]:0

    26 16:28:50 BM2LTSNuc64native-MCLI vdr: [1690] CAM 0: decrypts channel S19.2E-1-1005-13304 Feb


    _0226c_: vdr start 90s vor Aufnahme, 2 .ts, 2021-02-26.17.17.2-0.rec



    HelmutB

    1 Reicht bei _0226a_ die Vorlaufzeit (die 35s networking Verzög.) oder sollte sie länger sein, damit die Meldung Found CAM 0 vor dem switching zum Startkanal SIXX passiert oder an welcher Meldung von mcli und ncv sollte ich mich für die Verzögerung des vdr orientieren ?


    2 Warum kommt eig. die Meldung nicht mehr ... kommt das ev. weil damals viele plugins enabled waren (epgsearch, channelscan,...)

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


    3 Soll ich die debug x4000 und x100 weiter Beide nutzen ?

    Liebe Grüße g ;)

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

    3 Mal editiert, zuletzt von gggggg ()

  • cinfo : Darauf bin ich erst nach obigen Tests gestoßen: TimeoutStartSec=32sec  funkt nicht. Denn das definiert IMHO nur ein max. timeout:

    "Configures the time to wait for start-up. If a daemon service does not signail start-up completion within the configured time, the service will be considered failed and will be shut down again."

    Das funkt hingegen:

    [Service]

    ExecStartPre=/bin/sleep 10


    Hier noch ein Test mit ausreichend delay, sodass found CAM vor dem switching 17 kommt.


    0227e,f: hier wurde der vdr.service Start vezögert: switching17 ca. 9s nach found CAM, mit Meldung "FTA CAM-Trigger Pid 767 Sid 776"

    0227f hier kommt die FTA Meldung auch im ncv log


    0227i: hier wurde der networking.service Start vezögert, inkl. AC bereit: switch ca. 7s nach found CAM

    0227j: hier wurde der networking.service Start +5s vezögert, inkl. AC bereit: switch ca. 12s nach found CAM

    Hier kam es nach dem Umschalten auf ORF ca. 30-50s danach zu einem Freeze ! ??????????????

    EV. reichte hier das descrambling Timeout nicht aus ... was mich zu Punkt 5 vom letzten Post bringt ?!



    Code
    sekundenwerte lt. syslog für die Versionen e, f, i, j
    e  f    i  j
    36 41   58 09 boot
    11 07   23 34 Found CAM 0   
       16   26 39 'AlphaCrypt'-Modul bereit
    20 16   30 46 switch 17


    Manchmal hatte ich bei den Tests nach dem Start nur Ton aber kein Bild ... erst nach zappen kam es... Kann das mit 0x0100 Pid0 zusammen hängen ?

    Liebe Grüße g ;)

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

    5 Mal editiert, zuletzt von gggggg ()

  • 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

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

  • HelmutB Danke für die Analyse.

    1 Wann kommt eig. die FTA CAM-Trigger Pid 767 Sid 776 nicht ? ... weil in i+j fehlt sie ja auch


    2 Könntest du 0227j noch bez. des Freeze ansehen. Hängt dies mit einem noch immer zu kurzen descrambling timeout zusammen ?


    3 Wo könntest du den Parameter für das descrambling timeout als durch den User veränderbaren Wert einbauen ? Falls das nicht möglich ist, könntest du bitte den Wert auf 50s erhöhen ?


    4 Die Version 0228d hatte wieder mal kein Bild = nur Ton (kam erst nach Wechsel auf ORF2). Bei dieser Version kommt der FTA Trigger (vdr.service Verz.2s). Das Verhalten ist nicht reproduzierbar.

    0228c hatte die gleichen Einstellungen u keine Probs.

    Auch 0228e hat das Prob und da habe ich die logs sofort kopiert (sind also kürzer). Auch 0228h kein Bild .. d,e und h haben keine FTA Meldung im ncv log.

    Dafür aber gleich am Beginn "ERROR: NO CA/ES descriptors".

    Kann es sein dass das Prob durch x4000 auch FTA Sender betrifft und nachdem die keine descrambling Reaktion (eneutes switching) auslösen es dunkel bleibt (nämlich dann wenn der NCV beim FTA auch einen ERROR: produziert) ?


    ad errors im log) Ja an Plex bin ich dran ...

    Liebe Grüße g ;)

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

    15 Mal editiert, zuletzt von gggggg ()

  • 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

  • HelmutB danke ich bin gerade dabei BM2TS .28 von neu zu installieren um mal auf ein sauberes System zu setzen. Dann werde ich k testen...


    5 da auf der AVG gerade Aufnahmen laufen habe ich k mit mit log 0228k und maske 0x0df und bei log 0228l mit 0x40df getestet und keine .service Verzögerung eingebaut.

    Schon in der mcli095j ist uns aufgefallen, das bei 0x4... beim Startkanal der Ton immer eine Art Hall od. Vibrato hat. Wechselt man den Kanal ist es weg. Dies ist bei 0228l der Fall. 0228k (0xdf) ist OK.


    Hast du Punkt 4 zum Thema "kein Bild nur Ton" oben gesehen ?

    Liebe Grüße g ;)

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

    4 Mal editiert, zuletzt von gggggg ()

  • 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

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

  • Danke HelmutB

    1 Wie schon gepostet hat 0x4000 mit Sicherheit negative Auswirkungen auf Bild und Ton des FTA Startsenders.

    Heute war das Bild zwar immer da, aber der Ton hinkte immer um 1-3s dem Bild nach. Manchmal gab es auch Tondopplungen. Nach gefühlten 10-20s war es OK. Einmal blieb auch das Overlay unten am Bildschirmrand überlagert mit der Alphacrypt Meldung stehen.


    2 Zeitlicher Ablauf (Sekundewerte aus dem syslog)

    Code
    1a 1b 1c 1d 1e
    33 00 02 45 55 boot
    39 06 08 51 62 VDR version 2.4.6 started
    58 25 27 70 80 Found CAM 0
    62 27 29 72 82 switch 17
       27 29 72 82 FTA CAM-Trigger
    62 27 29 72 82 'AlphaCrypt'-Modul bereit
    29 27 27 27 27 DAUER boot bis switch

    Log Versionen 0301a (oben kurz 1a): debug x00df, keine Tonprobs

    33 ist der Sekundenwert lt. syslog wo der boot erfolgte, in Sekunde 39 "vdr started", 58 found CAM

    62 (eigentlich im slog 02) dann in der gelisteten Reihenfolge zuerst switch SIX, FTA, AC bereit.

    29s dauerte es von boot bis AC bereit


    1b, 1c: 40df:

    Tonprobs, und leider idente Zeiten und Abfolge wie bei x00df. Der switch kommt auch vor dem AC bereit.

    Ich weis nicht wie du das gelöst hast, aber ich würde nicht auf "* bereit" warten (was is wenn ein CAM sich anders meldet), sondern einfach einen Parameter TimeToWaitForCam einführen, den default mit 2s initialisieren und erst nach Abauf den switch machen. Aber ev. hast du mit dem ncv log eine andere Intepretation.


    1d, 1e: 50df und 1.Kanal in der channels.conf ist hier SIXX:

    Ich wollte den SIXX ein 2.Mal anwählen un hatte gehofft dass beim 2. Mal (ohne CAM Anfoderung) dann die Bild/Tonprobs weg sind.

    Aber die zus. x1000 hat eher nichts bewirkt.


    Könntest du testhalber wieder x8000 einführen, womit verschlüsselte Sender immer innerhalb von 1s ein 2.Mal angewählt werden.

    Ist auch 4000 gesetzt soll nach dem VdrStart der Startkanal zuerst mit CAM-Anforderung und 1s danach ein 2. Mal ohne CAM Anforderung erfolgen. Damit kann ich einige Varianen durchtesten.

    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 heute die Tests nochmal wiederholt und hochgeladen.

    x4000 produziert das Tonprob. das sich meist nicht von selbst löst und man muss den FTA Sender erneut anwählen .

    x1000 funkt in mcli k nur wenn vdr durch vdr.serviice verzögert wird ... siehe 2e/2f und 2g (hier ohne Verzögerung)


    Ich habe schon den Eindruck dass das einmalige anwählen des CAM mit 4000 die Anzahl der zus. switchings reduziert, aber verhindern tut es das nicht.

    Eig. würde ich vermuten dass das Schalten auf den 1. Kanal (ORF) in der channels per 1000 genauso funktionieren sollte, aber bei 2f gab es trotzdem 3 switchings.

    1 Ziel wäre es IMHO immer noch 4000 ohne Tonprobs. hin zu bekommen (ev. durch 2x switching im Abstand von 3s, die Idee mit x8000 von obigem Post). Auch heute blieb das Sender Overlay unten am Bildschirmrand überlagert mit der Alphacrypt Meldung fallweise stehen ... ev. ein REsultat dessen dass switch to Start und AC bereit immer gleichz. kommen.


    2 Auch die Option 1000 sollte ohne externe service Verzögerung funktionieren. Also nach "found CAM" Anwahl Kanal 1 und z.B. 3s danach Anwahl des Startkanals.


    3 Am Ende ist es immer die srambling dedection die Alles rettet. Warum ist die eig. nicht immer aktiv (ev. produziert sie false positive ;) ?
    (daher bitte bei Gelegenheit um den vdr Patch mit einfach erhöhtem descramblingtimeout auf z.B. 50s oder einem Parameter.)

    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 ()

  • 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

  • Danke @Helmut: 095k: Das Tonproblem bei Start FTA ist damit gelöst.


    1 Wie gesagt bleibt die Senderanzeige beim switching auf den Start FTA die von der AC bereit nochmal überlagert wird hin u wieder stehen. Daher mein obiger Vorschlag den FTA ein 2. Mal nach 1-3s anzuwählen ODER nach "found CAM" einfach 3-5s vor dem switching warten, dann ist die "AC bereit" schon weg.


    2. Ich habe zw. _40df (logs 0303a-c, 0305d) und A0df (logs 0303d.e) den Eindruck, dass 4000 bei der nachfolgenden Anwahl ORF2 manchmal länger bis zum 1. ORF-Bild als bisher braucht. Das wäre mir bei A0df nicht aufgefallen. Der FTA hat manchmal = wie bisher (also wenn der duchs CAM geht) Pixeling (Bildstörungen) in den ersten Sekunden. Das stört aber nicht weiter, da Bild u Ton synchron sind.


    3 bei 80df (logs 0303f, 0305a-c) kommt im ncv log FTA trough CAM, aber nicht im syslog. Der FTA Start läuft hier ohne Bildstörungen.

    Die Wahl des ORF kommt gefühlt schneller, aber das erneute switching kommt z.B. in 0305a erst nach 34s (also knapp vor dem desc. timeout nehme ich an).


    4 0305e nur mit 00df einfach zum Vergleich ...


    5 Ob 4000 od. 8000 auf die Anzahl der erneuten switches ein Einfluss hat, trau ich mir nicht sagen. Bei allen Varianten gab es erneute switchings.


    6 Bitte schau dir die ncv logs an ... ev. geben die dir Aufschluss, was 4000 / 8000 für Vorteile bringen.


    Liebe Grüße g ;)

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

  • 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

  • Hi,


    besser diese VDR Version für BM2LTS v3.4.32 und die MCLI 0.95m Version zum Testen


    cinfo

  • HelmutB ich hab die m mit der alten BM2LTS kurz angetestet. mit debug_mask 00df. Es ist kein Bild gekommen. Der Gegentest mit der l hat gefunkt.

    Mehr Zeit hatte ich leider nicht weil der waf sonst noch mehr gelitten hätte. Wenn du auf die Schnelle nix findest teste ich morgen weiter...

    Hier das m log

    Liebe Grüße g ;)

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

  • BM2LTS 3.4..32, vdr_mcli4, mcli095m4, --scrtmo=0


    HelmutB das schaut ja schon mal super aus. Der FTA ruckelt halt innerhalb der ersten 5s.

    1 Könnte das dann nach 30s neuerlich kommen ?


    2 schaltet man wie in 0306d, f sofort nach Bild auf ORF2 kommt es dort zu einem kurzen Ruckeln aber keinem neuerlichen switching ...

    in 0306e allerdings kam auf ORF2 kein Bild ... schaust dir das bitte an


    3 ab 0306g ist ORF2 der Startsender.

    In 0306h schalte ich nach ca 30s auf ORF1 und weitere ca. 30-40s danach hängt das ORF1 Bild. Bitte ansehen.


    Falls das nicht ohnehin so ist, sollte die desc. dedection min. 50s aktiv bleiben ...


    Liebe Grüße g ;)

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

  • 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

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

Jetzt mitmachen!

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