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?
[gelöst] mcli ERROR: video data stream broken
-
-
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
Code
Alles anzeigenFeb 26 17:15:24 BM2LTSNuc64native-MCLI vdr: [1615] switching to channel 17 S19.2E-133-5-776 (SIXX) Feb 26 17:15:24 BM2LTSNuc64native-MCLI vdr: [1632] Found CAM 0 Feb 26 17:16:08 BM2LTSNuc64native-MCLI vdr: [1615] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD) Feb 26 17:16:08 BM2LTSNuc64native-MCLI vdr: [1615] Mcli::CAMAlloc: AllocateCAM [(null)]:-1 -> [fe80::208:54ff:fe54:b261]:0 Feb 26 17:17:00 BM2LTSNuc64native-MCLI vdr: [1615] Mcli::CAMAvailable: Available CAM [(null)]:-1 -> [fe80::208:54ff:fe54:b261]:0 Feb 26 17:17:00 BM2LTSNuc64native-MCLI vdr: [1615] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD) Feb 26 17:17:11 BM2LTSNuc64native-MCLI vdr: [1685] CAM 0: won't decrypt channel S19.2E-1-1005-13304, detaching receiver Feb 26 17:17:11 BM2LTSNuc64native-MCLI vdr: [1684] recording thread ended (pid=1615, tid=1684) Feb 26 17:17:11 BM2LTSNuc64native-MCLI vdr: [1615] timer 2 (2 1717-1719 'Studio 2') stop Feb 26 17:17:11 BM2LTSNuc64native-MCLI vdr: [1615] removing /media/hd/recordings/Studio_2/2021-02-26.17.17.2-0.rec/.timer Feb 26 17:17:11 BM2LTSNuc64native-MCLI vdr: [1615] executing '/media/hd/recordings after "/media/hd/recordings/Studio_2/2021-02-26.17.17.2-0.rec"' Feb 26 17:17:11 BM2LTSNuc64native-MCLI vdr: [1615] Mcli::CAMAvailable: Available CAM [(null)]:-1 -> [fe80::208:54ff:fe54:b261]:0 Feb 26 17:17:11 BM2LTSNuc64native-MCLI vdr: [1615] switching device 2 to channel 2 S19.2E-1-1005-13304 (ORF2O HD) Feb 26 17:17:48 BM2LTSNuc64native-MCLI vdr: [1698] CAM 0: decrypts channel S19.2E-1-1005-13304
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 ?
-
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 ?!
Codesekundenwerte 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 ?
-
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.
Feb 27 10:37:10 BM2LTSNuc64native-MCLI vdr: [1631] VDR version 2.4.6 started
....
Feb 27 10:37:11 BM2LTSNuc64native-MCLI vdr: [1646] Found CAM 0
Feb 27 10:37:11 BM2LTSNuc64native-MCLI vdr: [1646] Mcli::Action: Add CAMs from NetCeiver: [fe80::208:54ff:fe54:b261] -> 1
Feb 27 10:37:11 BM2LTSNuc64native-MCLI vdr: [1646] Mcli::Action: Slot:0 CamModule 'AlphaCrypt' State:READY Mode:CA_MULTI_TRANSPONDER
Feb 27 10:37:11 BM2LTSNuc64native-MCLI vdr: [1646] Mcli::Action: Slot:1 CamModule State:MISSING
Feb 27 10:37:11 BM2LTSNuc64native-MCLI vdr: [1646] Mcli::Action: Add Tuner(#0): Conexant CX24116 DVB-S2 [fe80::208:54ff:fe54:b261:0400], Type 4 @ 1
Feb 27 10:37:11 BM2LTSNuc64native-MCLI vdr: [1646] Mcli::Action: Add Tuner(#1): Conexant CX24116 DVB-S2 [fe80::208:54ff:fe54:b261:0401], Type 4 @ 1
Feb 27 10:37:11 BM2LTSNuc64native-MCLI vdr: [1646] Mcli::Action: Add Tuner(#2): Conexant CX24116 DVB-S2 [fe80::208:54ff:fe54:b261:0402], Type 4 @ 1
Feb 27 10:37:11 BM2LTSNuc64native-MCLI vdr: [1646] Mcli::Action: Add Tuner(#3): Conexant CX24116 DVB-S2 [fe80::208:54ff:fe54:b261:0403], Type 4 @ 1
Feb 27 10:37:11 BM2LTSNuc64native-MCLI vdr: [1646] Mcli::Action: Add Tuner(#4): Conexant CX24116 DVB-S2 [fe80::208:54ff:fe54:b261:0404], Type 4 @ 1
Feb 27 10:37:11 BM2LTSNuc64native-MCLI vdr: [1646] Mcli::Action: Add Tuner(#5): Conexant CX24116 DVB-S2 [fe80::208:54ff:fe54:b261:0405], Type 4 @ 1
....Feb 27 10:37:20 BM2LTSNuc64native-MCLI vdr: [1631] remote control LIRC - keys known
Feb 27 10:37:20 BM2LTSNuc64native-MCLI vdr: [1631] loading /var/cache/vdr/cam.data
Feb 27 10:37:20 BM2LTSNuc64native-MCLI vdr: [1631] switching to channel 17 S19.2E-133-5-776 (SIXX)
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 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 ...
-
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 ?
-
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
-
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)
Code1a 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.
-
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.
Code
Alles anzeigen1a 1b 1c 1d 1e 2a 2b 2c 2d 2e=2f 2g 2h=2i 00 40 40 40 50 40 40 40 40 10 10 10 40 40 debugmask ..df 0 0 0 0 0 16 18 20 25 25 25 0 0 0 vdr.service verzögerung 33 00 02 45 55 17 13 20 55 40 39 31 07 55 boot 39 06 08 51 62 42 37 46 86 71 71 37 13 61 VDR version 2.4.6 started 58 25 27 70 80 44 38 47 88 73 73 56 31 80 Found CAM 0 xx xx xx xx xx xx xx xx xx 73 73 xx xx xx switch 1 62 27 29 72 82 52 48 57 97 82 81 58 34 82 switch 17 27 29 72 82 52 48 57 97 xx xx xx 34 82 FTA CAM-Trigger 62 27 29 72 82 xx 48 xx xx xx xx 58 34 82 AlphaCrypt-Modul bereit 29 27 27 27 27 35 35 37 42 42 42 27 27 27 DAUER boot bis switch 2 2 0 0 0 0 0 3 1 0 3 2 1 1 erneutes switching nach Wechsel auf verschlüsseltes Prog.
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.) -
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.
Code
Alles anzeigen2a 2b 2c 2d 2e 2f 2g 2h 2i 3a 3b 3c 3f 5a 5b 5c 5d 5e 40 40 40 40 10 10 10 40 40 40 40 40 80 80 80 80 40 00 debugmask ..df 16 18 20 25 25 25 0 0 0 0 0 0 0 0 0 0 0 0 vdr verzögerung 17 13 20 55 40 39 31 07 55 07 10 24 29 08 32 51 34 33 boot 42 37 46 86 71 71 37 13 61 13 17 30 35 15 39 57 40 40 VDR version 2.4.6 started 44 38 47 88 73 73 56 31 80 32 35 49 54 33 57 15 59 58 Found CAM 0 xx xx xx xx 73 73 xx xx xx xx xx xx xx xx xx xx xx xx switch 1 52 48 57 97 82 81 58 34 82 34 37 51 56 35 59 17 61 60 switch 17 52 48 57 97 xx xx xx 34 82 34 37 51 xx xx xx xx 61 xx FTA CAM-Trigger xx 48 xx xx xx xx 58 34 82 34 37 51 56 35 59 17 61 60 AlphaCrypt-Modul bereit 35 35 37 42 42 42 27 27 27 27 27 27 27 27 27 27 27 27 DAUER boot bis switch 11 44 71 11 17 switching to ORF2 15 77 05 15 42 switching to ORF2 0 0 3 1 0 3 2 1 1 0 7 4 1 1 2 3 1 3 erneute switchings
-
Ich habe mir fast gedacht, dass man mit der PAT-Pid 0 keinen CAPMT erzwingen kann, diese Option hat deshalb überhaupt keinen Effekt.
TUNED !
FTA -> THROUGH CAM!
NO ES PID - 0!
No free CI slot ! slot 0/1 slot 1/0
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:
+ " --scrtmo=SEC scrambled detection timeout of SEC seconds\n" ------> default 3 s - versuche einmal 5 s oder 10 s
+ " --descrtmo=SEC descrambled detection timeout of SEC seconds\n" ------> default 35 s
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 noch die 095m für den vdr mit dem "alten" mcli3 Patch.
LG Helmut
-
-
Nimm 0x40df. Und wenn es mehrere retunes gibt, starte vdr mit längerer scrambledetection "--scrtmo 5" oder 10.
Lg Helmut
-
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 ...
Code
Alles anzeigen3a 3b 3c 3f 5a 5b 5c 5d 5e 6a 6b 6c 6d 6e 6f 6g 6h 6i 40 40 40 80 80 80 80 40 00 40 40 40 40 40 40 40 40 40 debugmask ..df 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 vdr verzögerung 07 10 24 29 08 32 51 34 33 56 41 02 43 11 39 55 40 51 boot 13 17 30 35 15 39 57 40 40 03 47 09 50 17 45 02 46 58 VDR version 2.4.6 started 32 35 49 54 33 57 15 59 58 22 66 27 08 36 04 20 65 16 Found CAM 0 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 22 07 18 switch 2 34 37 51 56 35 59 17 61 60 25 68 29 10 39 08 xx xx xx switch 17 34 37 51 xx xx xx xx 61 xx 25 68 29 10 39 08 xx xx xx FTA CAM-Trigger 34 37 51 56 35 59 17 61 60 xx xx xx xx xx xx xx xx xx AlphaCrypt-Modul bereit 27 27 27 27 27 27 27 27 27 29 27 27 27 28 29 27 27 27 DAUER boot bis switch 11 44 71 11 17 57 87 58 15 45 11 22 07 18 switching to ORF2 15 77 05 15 42 26 switching to ORF2 35 57 switching to ORF1 0 7 4 1 1 2 3 1 3 0 0 0 0 0 0 1 0 0 erneute switchings
-
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 !
Mar 6 13:23:57 BM2LTS-N64native-MCLI vdr: [1091] ScrambleDetection timers set to 3 sec / 35 sec
Mar 6 13:24:07 BM2LTS-N64native-MCLI vdr: [1091] switching to channel 2 S19.2E-1-1005-13304 (ORF2O HD)
Mar 6 13:24:11 BM2LTS-N64native-MCLI vdr: GetFormat Init ok 1280x720
Mar 6 13:24:35 BM2LTS-N64native-MCLI vdr: [1091] switching to channel 1 S19.2E-1-1007-4911 (ORF1 HD)
Mar 6 13:24:43 BM2LTS-N64native-MCLI vdr: GetFormat Init ok 1280x720
Mar 6 13:25:19 BM2LTS-N64native-MCLI vdr: [1603] CAM 0: decrypts channel S19.2E-1-1007-4911
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
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!