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

gggggg · 13. August 2021

Zitat von HelmutB

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 60 // 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

Alles anzeigen

Zitat von HelmutB

gggggg : Die Parameter --srctmo, und --descrtmo sind im vdr-2.4.6.mcli4.patchenthalten. Du siehst die verwendeten Werte im syslog:

Spoiler anzeigen

LG Helmut

Zitat von HelmutB

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

Alles anzeigen

Hallo pbrb
#define TS_SCRAMBLING_TIMEOUT 3 // seconds to wait until a TS becomes unscrambled

Ich hab nun schon einige Monate TS_SCRAMBLING_TIMEOUT auf 5s. Daher ersuche ich dich das nun auch im define des Patch von 3 auf 5s nachzuziehen.

HelmutB Ev. sind wir von 17.9. am Donauinselfest ... da könnten wir uns ev. treffen und ich meine Schuld begleichen

pbrb · 14. August 2021

Könnt Ihr mal all die notwendigen Änderungen als Pull-Request "einliefern"? Dann merge ich die.

gggggg · 15. Januar 2022

Hallo HelmutB hoffe es geht dir gut ... wollte fragen ob du in nächster Zeit Obiges konsolidieren könntest ... sonst verdunstet es aus meinem alternden Hirn

HelmutB · 16. Januar 2022

Hallo Richard,

nachdem mit dem mcli5 Patch das Scrambling-Timeout als Plugin-Parameter nach eigenen Bedürfnissen angepasst werden kann, ist es nicht unbedingt notwendig, dem VDR einen bestimmten Wert vorzugeben.

Allerdings sollte das Scrambling-Timeout nicht größer als MAXBROKENTIMEOUT sein bei dem der VDR bei Aufnahmen einen Restart veranlässt. Deshalb hier die Änderung zum mcli5 patch mit 5 Sekunden-Timeout als default:

Diff: mcli5-mcli6.diff

diff -Nurp vdr-2.4.6.mcli5/device.c vdr-2.4.6.mcli6/device.c
--- vdr-2.4.6.mcli5/device.c    2021-03-13 20:52:33.817040124 +0100
+++ vdr-2.4.6.mcli6/device.c    2022-01-16 11:04:38.890110590 +0100
@@ -1765,6 +1765,8 @@ bool cDevice::GetTSPacket(uchar *&Data)
   return false;
 }
 
+#define MAX_TS_SCRAMBLING_TIMEOUT 29 // seconds, must be less then MAXBROKENTIMEOUT -> see recorde.c
+
 bool cDevice::AttachReceiver(cReceiver *Receiver)
 {
   if (!Receiver)
@@ -1805,7 +1807,7 @@ bool cDevice::AttachReceiver(cReceiver *
                Receiver->descramblingTimeout = DeScrambleTimeout;
                bool KnownToDecrypt = ChannelCamRelations.CamDecrypt(Receiver->ChannelID(), camSlot->MasterSlotNumber());
                if (KnownToDecrypt)
-                  Receiver->scramblingTimeout *= 10; // give it time to receive ECM/EMM
+                  Receiver->scramblingTimeout = MAX_TS_SCRAMBLING_TIMEOUT; // give it time to receive ECM/EMM
                if (Receiver->ChannelID().Valid())
                   dsyslog("CAM %d: %sknown to decrypt channel %s (scramblingTimeout = %ds)", camSlot->MasterSlotNumber(), KnownToDecrypt ? "" : "not ", *Receiver->ChannelID().ToString(), Receiver->scramblingTimeout);
                }
diff -Nurp vdr-2.4.6.mcli5/receiver.c vdr-2.4.6.mcli6/receiver.c
--- vdr-2.4.6.mcli5/receiver.c    2021-03-13 20:41:51.433684170 +0100
+++ vdr-2.4.6.mcli6/receiver.c    2022-01-16 00:27:31.170032434 +0100
@@ -11,7 +11,7 @@
 #include <stdio.h>
 #include "tools.h"
 
-#define TS_SCRAMBLING_TIMEOUT     3 // seconds to wait until a TS becomes unscrambled
+#define TS_SCRAMBLING_TIMEOUT     5 // seconds to wait until a TS becomes unscrambled
 #define TS_SCRAMBLING_TIME_OK    60 // seconds before a Channel/CAM combination is marked as known to decrypt
 
 int ScrambleTimeout = TS_SCRAMBLING_TIMEOUT;mci

Alles anzeigen

Im Anhang der vdr-2.4.6-mcli6.patch und ein VDR-Binary dazu. Ich hoffe, es läuft.

LG Helmut

gggggg · 21. Januar 2022

cinfo könntest du bitte die Änderung von Helmut bauen (weil sonst läuft das ja bei uns nicht oder lieg ich da falsch).

cinfo · 21. Januar 2022

ist wohl nicht für unseren VDR(-2.6.0) und unser mcli Plugin läuft.

Die Änderungen sollten in das Git vom Plugin aufgenommen werden --> dann können wir das

in die nächste Version von BM2LTS übernehmen.

gggggg · 21. Januar 2022

pbrb könntest du Obiges bitte ins GIT bringen. HelmutB danke für deine obigen Anpassungen.

Anderes Thema:

cinfo ich hab seit jeher ein Prob mit der Multitranspondereinstellung unter BM2LTS-SYSTEM>Common Interface:
Ein Änderung der Einstellung funktioniert bisher leider nicht

Code

Jan 21 15:33:51 BM2LTSnativeMC vdr[4858]: UUID fe80::208:54ff:fe54:b261: Downloading netceiver.conf ...
Jan 21 15:33:51 BM2LTSnativeMC vdr[4860]: ftp: q: unknown option
Jan 21 15:33:51 BM2LTSnativeMC vdr[4858]: Download failed (ret=256)
Jan 21 15:33:51 BM2LTSnativeMC vdr[1634]: I/O warning : failed to load external entity "/tmp/netceiver.conf"
Jan 21 15:33:51 BM2LTSnativeMC vdr: [1634] warning: Fehler beim Parsen der Konfiguration von Netceiver fe80::208:54ff:fe54:b261

Das liegt ja an der nicht mehr vorhandenen -q Option..... Daher ändere ich die Einstellungen immer noch mit der alten Reelbox BM2LTS 2.94.

- Irgendwann wird die aber das Zeitliche segnen

- weiters ist es am NUC schon immer so, dass wenn ich eine Factory mache, genau diese Multitranspondereinstellung auf NEIN gestellt wird. Wie kann das sein ? (Hängt es ev. mit dem KODI Mode zusammen mit dem die Factory das 1.MAl hochfährt ...)

Jedenfalls wäre mein Ersuchen, ob du eine Möglichkeit siehst das Senden des netceiver.conf per CAM-Menü zu reparieren.

Manuell mache ich das so:

Download: netcvupdate -d eth1.2 -i fe80::208:54ff:fe54:b261 -D

Upload: netcvupdate -d eth1.2 -i fe80::208:54ff:fe54:b261 -U netceiver.conf

Aktivieren durch Reset: netcvupdate -d eth1.2 -i fe80::208:54ff:fe54:b261 -K

cinfo · 21. Januar 2022

Zitat

- weiters ist es am NUC schon immer so, dass wenn ich eine Factory mache, genau diese Multitranspondereinstellung auf NEIN gestellt wird. Wie kann das sein ? (Hängt es ev. mit dem KODI Mode zusammen mit dem die Factory das 1.MAl hochfährt ...)

Hm, ist das beim BM2LTS v4.0.26 Image auch so?

Jedenfalls wäre mein Ersuchen, ob du eine Möglichkeit siehst das Senden des netceiver.conf per CAM-Menü zu reparieren.

eigentlich schreibt hier nichts beim Start auf den NetCeiver --- das wäre ja dann auch der Fall bei jeden Neustart vom VDR.

gggggg · 21. Januar 2022

cinfo hab ein Prob bei der neuen Version. mcli startet nach Reboot nicht weil es das eth nicht findet ...

Code

Jan 21 17:54:16 BM2LTSnativeMC vdr: [1340] initializing plugin: mcli (0.9.6-3-BM2LTS): NetCeiver Client Application
Jan 21 17:54:16 BM2LTSnativeMC vdr: [1340] mcli::Initialize: called
Jan 21 17:54:16 BM2LTSnativeMC vdr: [1340] mcli::PreInitMcli: called with m_cmd.iface='eth0.2' builtin watch-timeout=180 watch-step=5
Jan 21 17:54:16 BM2LTSnativeMC vdr: [1340] mcli::PreInitMcli: can't find specified device 'eth0.2' in /proc/net/if_inet6
Jan 21 17:54:16 BM2LTSnativeMC vdr: [1340] mcli::Initialize: PreInitMcli failed

mach ich danach ein systemctl start vdr.service findet er es sofort:

Code

Jan 21 18:01:30 BM2LTSnativeMC vdr: [1880] mcli::Initialize: called
Jan 21 18:01:30 BM2LTSnativeMC vdr: [1880] mcli::PreInitMcli: called with m_cmd.iface='eth0.2' builtin watch-timeout=180 watch-step=5
Jan 21 18:01:30 BM2LTSnativeMC vdr: [1883] reading EPG data from /var/cache/vdr/epg.data
Jan 21 18:01:30 BM2LTSnativeMC vdr: [1880] mcli::PreInitMcli: found specified device 'eth0.2' in /proc/net/if_inet6 (after 0 sec)

HelmutB Könnte es sein dass der 180 sec timer watch-timeout=180 watch-step=5 beim vdr2.6 nicht funktioniert oder lauft da beim systemd Ablauf ev was falsch ?

cinfo · 22. Januar 2022

Hi,

hier mal zum Testen

hab ein Prob bei der neuen Version. mcli startet nach Reboot nicht weil es das eth nicht findet ...

Das Problem hat der mcli hier beim testen nicht

Ich habe mal zum Testen den VDR-2.6.0 mit den vdr-2.4.6.mcli5_mcli6.diff versorgt und das mcli Plugin aus den aktuellem Git Stand MCLI_PLUGIN_VERSION "0.9.6.99.alpha.1" gebaut zum Testen

Wenn Änderungen am Plugin mcli benötigt werden dann sollten Diese auf den letzten GIT Stand beruhen

gggggg · 22. Januar 2022

Mit den von THX cinfo geposteten Versionen läuft es ... auch hier kommt zuerst der Fehler:

Der NetworkManager meldet den Link ja auch erst nachher als OK.
(Ev. ist es bei mir anders, da ich in etc/network/interfaces für den Fall dass der Router nicht läuft eine statische IP vergeben habe)

Code

11:51:44 vdr: [1317] initializing plugin: mcli (0.9.6.99.alpha.1-BM2LTS): NetCeiver Client Application
11:51:44 vdr: [1317] mcli::Initialize: called
11:51:44 vdr: [1317] mcli::PreInitMcli: called with m_cmd.iface='eth0.2' builtin watch-timeout=180 watch-step=5
11:51:44 vdr: [1317] mcli::PreInitMcli: can't find specified device 'eth0.2' in /proc/net/if_inet6 (after 0 of 180 sec / wait next 5 sec)
11:51:44 vdr: [1329] video directory scanner thread ended (pid=1317, tid=1329)
11:51:44 vdr: [1330] epg data reader thread ended (pid=1317, tid=1330)
11:51:44 NetworkManager[608]: <info>  [1642848704.8122] device (eth0): carrier: link connected
11:51:44 kernel: [    6.809120] e1000e 0000:00:1f.6 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
11:51:44 kernel: [    6.809203] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
11:51:44 kernel: [    6.809376] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.2: link becomes ready
11:51:44 NetworkManager[608]: <info>  [1642848704.8128] device (eth0.2): carrier: link connected
11:51:45 avahi-daemon[602]: Joining mDNS multicast group on interface eth0.2.IPv6 with address fe80::1e69:7aff:fea3:e6b3.
11:51:45 avahi-daemon[602]: New relevant interface eth0.2.IPv6 for mDNS.
11:51:45 avahi-daemon[602]: Registering new address record for fe80::1e69:7aff:fea3:e6b3 on eth0.2.*.
11:51:46 avahi-daemon[602]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::1e69:7aff:fea3:e6b3.
11:51:46 avahi-daemon[602]: New relevant interface eth0.IPv6 for mDNS.
11:51:46 avahi-daemon[602]: Registering new address record for fe80::1e69:7aff:fea3:e6b3 on eth0.*.

Alles anzeigen

Dann kommt die OK Meldung:

Code

Jan 22 11:51:49 BM2LTSnativeMC vdr: [1317] mcli::PreInitMcli: found specified device 'eth0.2' in /proc/net/if_inet6 (after 5 sec)
Jan 22 11:51:49 BM2LTSnativeMC vdr: [1317] mcli::Initialize: successful

Die von Danke HelmutB umgebaute default Verzögerung 5s ist auch OK:
Jan 22 12:14:39 BM2LTSnativeMC vdr: [2039] ScrambleDetection timers set to 5 sec / 60 sec

Helmut, die Meldung kommt nur bei gesetzter Debug mask .. war das deine Absicht?

cinfo was war eig. das Prob ?
und kann pbrb diese Version dann ins GIT pflegen oder brauchen wir noch HelmutB dazu ?

pbrb · 22. Januar 2022

Zitat von gggggg

und kann pbrb diese Version dann ins GIT pflegen oder brauchen wir noch HelmutB dazu ?

Ich brauch den Diff oder einen Pull-Request gegen den aktuellen "master", dann pflege ich es gerne ein.

gggggg · 22. Januar 2022

Zitat von pbrb

Ich brauch den Diff oder einen Pull-Request gegen den aktuellen "master", dann pflege ich es gerne ein.

Danke f. die schnelle Antwort ... versteh ich das richtig... den von HelmutB oben geposteten .diff kannst du nicht nehmen weil er nicht gegen den aktuellen Master geht ?

cinfo · 22. Januar 2022

Zitat von gggggg

Danke f. die schnelle Antwort ... versteh ich das richtig... den von HelmutB oben geposteten .diff kannst du nicht nehmen weil er nicht gegen den aktuellen Master geht ?

Die oben geposteten *.diff Datei geht gegen den VDR und nicht gegen das MCLI Plugin

pbrb · 22. Januar 2022

welche oben geposteten diff/patch Dateien sollen noch nicht im "master" drin sein? Den letzten den ich hier sehe (ggf. bin ich aber blind) ist von März 2021...in Posting #271 sind nur 2x tar.bz2 mit Binaries drin...

gggggg · 22. Januar 2022

pbrb Bin kein Softwerker dachte an die Files in #264

cinfo · 22. Januar 2022

Zitat von pbrb

welche oben geposteten diff/patch Dateien sollen noch nicht im "master" drin sein? Den letzten den ich hier sehe (ggf. bin ich aber blind) ist von März 2021...in Posting #271 sind nur 2x tar.bz2 mit Binaries drin...

richtig, es gibt keine für den "master" -- Der Diff geht gegen den VDR zur Nutzung des "master"

gggggg · 22. Januar 2022

Zitat von cinfo

Hm, ist das beim BM2LTS v4.0.26 Image auch so?

Ich hab diesmal ohne Netzwerk mit route66 auf mcli umgestellt (somit hatte keiner eine Chance mein ncv.conf zu killen ;-). Kann ich beim nächsten Image testen.

Jedenfalls wäre mein Ersuchen, ob du eine Möglichkeit siehst das Senden des netceiver.conf per CAM-Menü zu reparieren.

cinfo · 22. Januar 2022

Zitat von gggggg

Ich hab diesmal ohne Netzwerk mit route66 auf mcli umgestellt (somit hatte keiner eine Chance mein ncv.conf zu killen ;-). Kann ich beim nächsten Image testen.

Jedenfalls wäre mein Ersuchen, ob du eine Möglichkeit siehst das Senden des netceiver.conf per CAM-Menü zu reparieren.

schwer, da hier keiner ein CAM am NetCeiver nutzt -- da es hier kein Problem macht, vermute ich das es beim initialisieren des CAM Moduls erfolgt .

gggggg · 22. Januar 2022

Code

Jan 21 15:33:51 BM2LTSnativeMC vdr[4858]: UUID fe80::208:54ff:fe54:b261: Downloading netceiver.conf ...
Jan 21 15:33:51 BM2LTSnativeMC vdr[4860]: ftp: q: unknown option
Jan 21 15:33:51 BM2LTSnativeMC vdr[4858]: Download failed (ret=256)
Jan 21 15:33:51 BM2LTSnativeMC vdr[1634]: I/O warning : failed to load external entity "/tmp/netceiver.conf"
Jan 21 15:33:51 BM2LTSnativeMC vdr: [1634] warning: Fehler beim Parsen der Konfiguration von Netceiver fe80::208:54ff:fe54:b261

Ich dachte es geht lediglich darum das -q beim Download Befehl weg zu lassen.Die Befehle hab ich ja da beschrieben.

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

Jetzt mitmachen!

Teilen