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

cinfo · 13. März 2021

hm, wurde doch bei device.c.diff gelöscht

cinfo

HelmutB · 13. März 2021

Die beiden TS_SCRAMBLING.. #defines habe ich nur von device.c nach receiver.c verschoben.

LG Helmut

gggggg · 13. März 2021

HelmutB danke f die neue Version: 095n4, Startkanal ORF2, logs wie immer ;-)

0313a 00df, osdtltext: Nach Umschalten auf ORF1 kein Bild, keine decrypt Meldung, kein mcg: nach PMT delete.

0313b 40df, NO osdtltext: Bereits ORF2 hängt nach einigen Sekunden. logs wie 0313a.

0313c Start SIXX, 00df, osdtltext: Ca. 20s nach Umschalten auf ORF2 hängt das Bild

0313d Start SIXX, 40df, NO osdtltext: NAch Umschlten auf ORF2 kein Bild

Ich nehme für den WAF einstweilen 095m mit Start SIXX und x40df oder ?

gggggg · 13. März 2021

Epgsearch hat mir den ORFs auch noch seine liebe Not:

Nachdm ich am ORF einen Suchtimer angelegt habe crasht der vdr und dann hängt er in der crash Schleife fest:

Grund: Beim timer conflict check rast er jedes mal wieder ... siehe am Ende des logs

Code

59:48 vdr: [1085] starting plugin: epgsearch
59:48 vdr: [1085] loading /var/lib/vdr/plugins/epgsearch/epgsearchcats.conf
59:48 vdr: [1085] loading /var/lib/vdr/plugins/epgsearch/epgsearchmenu.conf
59:48 vdr: [1172] epg data reader thread ended (pid=1085, tid=1172)
59:48 vdr: [1085] loading /var/lib/vdr/plugins/epgsearch/epgsearchuservars.conf
59:48 vdr: [1085] loading /var/lib/vdr/plugins/epgsearch/epgsearchchangrps.conf
59:48 vdr: [1085] loading /var/lib/vdr/plugins/epgsearch/epgsearchblacklists.conf
59:48 vdr: [1085] EPGSearch: loading /var/lib/vdr/plugins/epgsearch/epgsearch.conf
59:48 vdr: [1085] EPGSearch: loading /var/lib/vdr/plugins/epgsearch/epgsearchtemplates.conf
59:48 vdr: [1085] EPGSearch: loading /var/lib/vdr/plugins/epgsearch/epgsearchdone.data
59:48 vdr: [1085] loading /var/lib/vdr/plugins/epgsearch/epgsearchswitchtimers.conf
59:48 vdr: [1085] loading /var/lib/vdr/plugins/epgsearch/timersdone.conf
59:48 vdr: [1085] EPGSearch: loading /var/lib/vdr/plugins/epgsearch/epgsearchupdmail.templ
59:48 vdr: [1085] starting plugin: femon
59:48 vdr: [1085] starting plugin: live
59:48 vdr: [1185] EPGSearch: searchtimer thread started (pid=1085, tid=1185, prio=high)
59:48 vdr: [1085] live: initial file cache has 82 entries and needs 377394 bytes of data!
59:48 vdr: [1085] loading /opt/vdr/plugins/live/users.conf
59:48 vdr: [1085] starting plugin: mpv
59:48 vdr: [1085] starting plugin: osdteletext
59:48 vdr: [1085] OSD-Teletext: Error statfs'ing root directory "/run/shm/vtx": Datei oder Verzeichnis nicht gefunden, cache size uncontrolled
59:48 vdr: [1085] starting plugin: softhddrm
59:48 vdr: [1186] live: INFO: attempt to listen on ip = '10.75.25.22'
59:48 vdr: [1186] live: ERROR: Unable to load cert/key (/opt/vdr/plugins/live/live.pem//opt/vdr/plugins/live/live-key.pem): Datei oder Verzeichnis nicht gefunden
59:48 vdr[1085]: FindDevice: open /dev/dri/card0:  i915
59:48 vdr: [1085] starting plugin: systeminfo
59:48 vdr: [1085] starting plugin: mcli
59:48 vdr: [1085] Mcli v0.9.5m started
59:48 vdr: [1085] remote control XKeySym - learning keys
59:48 systemd[1]: Started Video Disk Recorder.
59:48 systemd[1]: Reached target Multi-User System.
59:48 systemd[1]: Starting Update UTMP about System Runlevel Changes...
59:48 vdr: [1205] LIRC remote control thread started (pid=1085, tid=1205, prio=high)
59:48 systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
59:48 systemd[1]: Finished Update UTMP about System Runlevel Changes.
59:48 systemd[1]: Startup finished in 3.857s (kernel) + 8.319s (userspace) = 12.176s.
59:48 vdr: [1085] [softhddev]CreateOsd: left 96, top 54, level 0, using OpenGL OSD support
59:48 vdr: [1085] [softhddev]Trying to start OpenGL Worker Thread
59:48 vdr: [1208] oglThread thread started (pid=1085, tid=1208, prio=high)
59:50 vdr: [1204] 2 tuner available: enabling 2 devices
59:51 systemd[1]: NetworkManager-dispatcher.service: Succeeded.
59:52 systemd[1]: Created slice User Slice of UID 0.
59:52 systemd[1]: Starting User Runtime Directory /run/user/0...
59:52 systemd[1]: Finished User Runtime Directory /run/user/0.
...
59:58 vdr: [1085] remote control LIRC - keys known
59:58 vdr: [1085] loading /var/cache/vdr/cam.data
59:58 vdr: [1085] ScrambleDetection timers set to 3 sec / 35 sec
59:58 vdr: [1085] switching to channel 17 S19.2E-133-5-776 (SIXX)
59:58 vdr: [1085] Mcli::SetChannelDevice: add dummy Pid 0
59:58 vdr: [1085] creating directory /run/shm/vtx
59:58 vdr: [1085] creating directory /run/shm/vtx/S19.2E-133-5-776
59:58 vdr: [1527] device 2 receiver thread started (pid=1085, tid=1527, prio=high)
59:58 vdr: [1085] [softhddev]SetVolumeDevice: 27
59:58 vdr: [1528] osdteletext-receiver thread started (pid=1085, tid=1528, prio=high)
59:58 vdr: [1529] SVDRP server handler thread started (pid=1085, tid=1529, prio=low)
59:58 vdr: [1529] SVDRP 10.75.25.22 opening port 2001/tcp
59:58 vdr: [1529] SVDRP 10.75.25.22 listening on port 2001/tcp
59:58 vdr: [1085] [softhddev]SetPlayMode: 1
59:58 vdr: [1530] SVDRP client handler thread started (pid=1085, tid=1530, prio=low)
59:58 vdr: [1530] SVDRP 10.75.25.22 opening port 6419/udp
59:58 vdr: [1530] SVDRP 10.75.25.22 listening on port 6419/udp
59:58 vdr: [1530] SVDRP 10.75.25.22 > 255.255.255.255:6419 send dgram 'SVDRP:discover name:10.75.25.22 port:2001 vdrversion:20406 apiversion:20406 timeout:300'
59:58 vdr: [1530] SVDRP 10.75.25.22 < 10.75.25.22:51680 discovery ignored (SVDRP:discover name:10.75.25.22 port:2001 vdrversion:20406 apiversion:20406 timeout:300)
59:58 vdr: [1085] OSD size changed to 1920x1080 @ 1
59:58 vdr: [1085] [softhddev]CreateOsd: left 96, top 679, level 0, using OpenGL OSD support
59:58 vdr: [1085] [softhddev]cOglOsd osdLeft 96 osdTop 679 screenWidth 1920 screenHeight 1080
59:58 vdr: [1085] timer 1 (22 1813-1923 'Die Aquarium-Profis~Episode 78') set to event Sa. 13.03.2021 18:15-19:15 'Die Aquarium-Profis'
59:58 vdr: [1085] timer 2 (22 1913-2023 'Die Aquarium-Profis~Episode 79') set to event Sa. 13.03.2021 18:15-19:15 'Die Aquarium-Profis'
59:58 vdr: [1085] timer 3 (1 2158-2253 'New Amsterdam~Dankbarkeit') set to event Mo. 15.03.2021 22:00-22:45 (VPS: 15.03. 22:00) 'New Amsterdam'
59:58 vdr: [1085] timer 4 (1 0158-0248 'New Amsterdam~Dankbarkeit') set to event Di. 16.03.2021 02:00-02:40 (VPS: 16.03. 01:55) 'New Amsterdam'
59:59 vdr: [1185] EPGSearch: search timer update started
59:59 vdr: [1185] timer 0 (22 1810-1922 'Die Aquarium-Profis') set to event Sa. 13.03.2021 18:15-19:15 'Die Aquarium-Profis'
59:59 vdr: [1185] timer 0 (89 1810-1922 'Die Aquarium-Profis') set to event Sa. 13.03.2021 18:15-19:15 'Die Aquarium-Profis'
59:59 vdr: [1185] timer 0 (1 2200-2245 VPS 'New Amsterdam') set to event Mo. 15.03.2021 22:00-22:45 (VPS: 15.03. 22:00) 'New Amsterdam'
59:59 vdr: [1185] timer 0 (1 0155-0235 VPS 'New Amsterdam') set to event Di. 16.03.2021 02:00-02:40 (VPS: 16.03. 01:55) 'New Amsterdam'
59:59 vdr: [1185] timer 0 (1 1840-1930 VPS 'Soko Donau') set to event Sa. 13.03.2021 18:20-19:10 (VPS: 13.03. 18:40) 'Soko Donau'
59:59 vdr: [1185] timer 0 (29 1840-1930 VPS 'Soko Donau') set to event Sa. 13.03.2021 18:20-19:10 (VPS: 13.03. 18:40) 'Soko Donau'
59:59 vdr: [1185] timer 0 (1 2015-2105 VPS 'Soko Donau') set to event Di. 16.03.2021 20:15-21:05 (VPS: 16.03. 20:15) 'Soko Donau'
59:59 vdr: [1185] timer 0 (29 2015-2105 VPS 'Soko Donau') set to event Di. 16.03.2021 20:15-21:05 (VPS: 16.03. 20:15) 'Soko Donau'
59:59 vdr: [1185] timer 0 (1 0235-0320 VPS 'Soko Donau') set to event Mi. 17.03.2021 01:40-02:25 (VPS: 17.03. 02:35) 'Soko Donau'
59:59 vdr: [1185] timer 0 (29 0235-0320 VPS 'Soko Donau') set to event Mi. 17.03.2021 02:35-03:20 (VPS: 17.03. 02:35) 'Soko Donau'
59:59 vdr: [1185] timer 0 (2 2120-2200 VPS 'Vera') set to event Fr. 19.03.2021 21:20-22:00 (VPS: 19.03. 21:20) 'Vera'
59:59 vdr: [1185] timer 0 (67 2120-2200 VPS 'Vera') set to event Fr. 19.03.2021 21:20-22:00 (VPS: 19.03. 21:20) 'Vera'
59:59 vdr: [1185] timer 0 (68 2120-2200 VPS 'Vera') set to event Fr. 19.03.2021 21:20-22:00 (VPS: 19.03. 21:20) 'Vera'
59:59 vdr: [1185] timer 0 (69 2120-2200 VPS 'Vera') set to event Fr. 19.03.2021 21:20-22:00 (VPS: 19.03. 21:20) 'Vera'
59:59 vdr: [1185] timer 0 (70 2120-2200 VPS 'Vera') set to event Fr. 19.03.2021 21:20-22:00 (VPS: 19.03. 21:20) 'Vera'
59:59 vdr: [1185] timer 0 (71 2120-2200 VPS 'Vera') set to event Fr. 19.03.2021 21:20-22:00 (VPS: 19.03. 21:20) 'Vera'
59:59 vdr: [1185] timer 0 (72 2120-2200 VPS 'Vera') set to event Fr. 19.03.2021 21:20-22:00 (VPS: 19.03. 21:20) 'Vera'
59:59 vdr: [1185] timer 0 (73 2120-2200 VPS 'Vera') set to event Fr. 19.03.2021 21:20-22:00 (VPS: 19.03. 21:20) 'Vera'
59:59 vdr: [1185] timer 0 (74 2120-2200 VPS 'Vera') set to event Fr. 19.03.2021 21:20-22:00 (VPS: 19.03. 21:20) 'Vera'
59:59 vdr: [1185] timer 0 (1 2015-2110 VPS 'Vorstadtweiber') set to event Mo. 15.03.2021 20:15-21:10 (VPS: 15.03. 20:15) 'Vorstadtweiber'
59:59 vdr: [1185] timer 0 (1 0105-0155 VPS 'Vorstadtweiber') set to event Di. 16.03.2021 01:10-02:00 (VPS: 16.03. 01:05) 'Vorstadtweiber'
59:59 vdr: [1529] SVDRP 10.75.25.22 < 127.0.0.1:40258 client connection accepted
59:59 vdr: [1529] SVDRP 10.75.25.22 > 127.0.0.1:40258 server created
59:59 vdr: [1529] SVDRP 10.75.25.22 < 127.0.0.1:40258 deleted timer 2 (22 1913-2023 'Die Aquarium-Profis~Episode 79')
59:59 vdr: [1529] SVDRP 10.75.25.22 < 127.0.0.1:40258 connection closed
59:59 vdr: [1529] SVDRP 10.75.25.22 < 127.0.0.1:40258 server destroyed
59:59 vdr: [1185] EPGSearch: search timer update finished
59:59 vdr: [1185] EPGSearch: check for timer conflicts
59:59 kernel: [   23.189821] show_signal: 16 callbacks suppressed
59:59 kernel: [   23.189824] traps: EPGSearch: sear[1185] general protection fault ip:7f9162b8ed0a sp:7f9152214a30 error:0 in libvdr-epgsearch.so.2.4.6[7f9162b74000+ab000]
59:59 systemd[1]: vdr.service: Main process exited, code=killed, status=11/SEGV
59:59 systemd[1]: vdr.service: Failed with result 'signal'.

Alles anzeigen

da hängt der vdr dann in einer crash Schleife, weil der confilct check beim Start läuft

Erst wenn ich die ORF-Timer aus der timer.conf lösche kommt der vdr wieder hoch ...

Code

1:S19.2E-1-1007-4911:2021-03-15:2158:2253:50:99:New Amsterdam~Dankbarkeit:<epgsearch><channel>1 - ORF1 HD</channel><searchtimer>New Amsterdam</searchtimer><start>1615841880</start><stop>1615845180</stop><s-id>1</s-id><eventid>44827</eventid></epgsearch>
1:S19.2E-1-1007-4911:2021-03-16:0158:0248:50:99:New Amsterdam~Dankbarkeit:<epgsearch><channel>1 - ORF1 HD</channel><searchtimer>New Amsterdam</searchtimer><start>1615856280</start><stop>1615859280</stop><s-id>1</s-id><eventid>44833</eventid></epgsearch>

HelmutB · 13. März 2021

Im 'vdr-2.4.6.mcli4.patch' habe ich durch eine kleine Änderung die scrambleDetection unbrauchbar gemacht.

Hier der 'vdr-2.4.6.mcli5.patch' bei dem das wieder richtiggestellt ist. Gleichzeitig habe ich die TS_SCRAMBLING_TIME_OK nun auf 60 sec. eingestellt.

Das mcli-Plugin ist unverändert die Version 0.9.5n, im Anhang aber eine Binary gegen den Vdr mit dem mcli5.patch.

gggggg : Bei deinen 3 Logs von heute Vormittag war wieder MULTI_SID eingestellt. Das funktioniert zumindest auf dem NUC nicht brauchbar, da damit das CAM genau einem Device zugeordnet wird. Ein Ändern der Zuordnung auf ein anderes Device (z.B. bei Transponderwechsel ORF2 -> ORF1) geht mit dem vorhandenen Code vielleicht bei FullFeatured Devices, aber nicht im Transfermode wie beim NUC - warum auch immer.

Mar 13 10:50:21 BM2LTS-N64native-MCLI vdr: [1085] Mcli::SetChannelDevice: failed to get CAM on DVB 3 (cam_force=false)

Also im Netceiver immer MULTI_TRANSPONDER einstellen.

LG Helmut

gggggg · 14. März 2021

095n5

Danke HelmutB . Welche debug mask soll ich testen ... df u 40df ?

0314a Der vdr crasht ... ev. liegt es an deinem build ?!

Code

Mar 14 09:00:35 BM2LTS-N64native-MCLI vdr[1093]: /usr/sbin/vdr: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory
Mar 14 09:00:35 BM2LTS-N64native-MCLI xinetd[1092]: Reading included configuration file: /etc/xinetd.d/echo-udp [file=/etc/xinetd.d/echo-udp] [line=26]
Mar 14 09:00:35 BM2LTS-N64native-MCLI xinetd[1092]: Reading included configuration file: /etc/xinetd.d/servers [file=/etc/xinetd.d/servers] [line=14]
Mar 14 09:00:35 BM2LTS-N64native-MCLI xinetd[1092]: Reading included configuration file: /etc/xinetd.d/services [file=/etc/xinetd.d/services] [line=13]
Mar 14 09:00:35 BM2LTS-N64native-MCLI xinetd[1092]: Reading included configuration file: /etc/xinetd.d/time [file=/etc/xinetd.d/time] [line=13]
Mar 14 09:00:35 BM2LTS-N64native-MCLI systemd[1]: vdr.service: Main process exited, code=exited, status=127/n/a
Mar 14 09:00:35 BM2LTS-N64native-MCLI xinetd[1092]: Reading included configuration file: /etc/xinetd.d/time-udp [file=/etc/xinetd.d/time-udp] [line=28]
Mar 14 09:00:35 BM2LTS-N64native-MCLI systemd[1]: vdr.service: Failed with result 'exit-code'.
Mar 14 09:00:35 BM2LTS-N64native-MCLI xinetd[1092]: 2.3.15.3 started with libwrap loadavg labeled-networking options compiled in.
Mar 14 09:00:35 BM2LTS-N64native-MCLI systemd[1]: Failed to start Video Disk Recorder.

cinfo bitte vdr neu bauen

cinfo · 14. März 2021

hier zum Testen in BM2LTS 3.4.32

cinfo

gggggg · 14. März 2021

095n5 vdr5cinfo MTD=ein, logs wie immer

HelmutB !!!DANKE!!!

0314b x00df, orf2>orf1, mit osdtxt, epgsearch ... schaut wieder gut aus

0314c x40df, orf2>orf1, mit osdtxt, epgsearch ... OK

0314d x40df, orf2>orf1, NO osdtxt, epgsearch ... OK

0314e x40df, sixx>orf2, NO osdtxt, epgsearch ... OK

0314f x40df, sixx>orf2, mit osdtxt, epgsearch ... OK

0314g x00df, sixx>orf2, mit osdtxt, epgsearch ... OK

0314h x00df, sixx>orf2, mit osdtxt, epgsearch, crash wegen timer conflict check.

1 Ich denke der vdr crashed bei jedem Aufruf von conflict check ... egal ob beim Start od. nach einer Timerprogrammierung. Aber verm. hängt es schon mit der BM2LTS/mcli Kombi zusammen.

2 60-mcli.conf

sind wir sicher dass mcli erst nach Allen anderen Plugins staten soll oder macht das bei Plugins wie epgsearch u osdteletext eher Probs? Ich hätte es eher vorab starten lassen ..40- ?!

3 Welche Kombi soll ich noch testen ?

4 Was sollen wir "im Alltag" als debug_mask einstellen bzw. welche Methode hast du nun als default (ohne mask) ?

HelmutB · 14. März 2021

Schön, dass das Retune jetzt wieder funktioniert. Mit deinen Plugins bzw. deren Reihenfolge kann ich dir leider nicht helfen - einfach ausprobieren ob es eine besondere Reihenfolge braucht.

Ich brauche keine weiteren Tests, du kannst natürlich zum deinem Ausgangsproblem zurück und eine verschlüsselte Timeraufnahme testen.

Die Bildstörungen bzw. das Retune treten ja nur bei verschlüsselten Programmen und irgendwann in den ersten 60 sec. nach dem Power-On auf, Timeraufnahmen die danach beginnen sind daher nicht mehr betroffen.

Deine "Alltags" debug_mask ist ja inzwischen schon "Hart" einprogrammiert - TS_SCRAMBLING_TIME_OK mit 60s im vdr-mcli5 und TRIGGER_CAM mit 0x4000 im mcli-0.9.5n Plugin (das sich aber noch als "m" meldet). Mehr brauchst du nicht. Das Loggen mit 0xdf kannst du auch weglassen.

LG Helmut

gggggg · 15. März 2021

HelmutB Danke,

- wenn ich mich nicht irre ist der PID 0 auch wieder Standard oder ?

- bringt aus deiner Sicht das CA=11 eig. etwas ?

- beschreibst du noch kurz die verbliebenen debug_masks (wirkt 1000,2000,8000 noch,...). Damit das final für Alle klar ist

SurfaceCleanerZ · 15. März 2021

Hi,

Eine solche Beschreibung sollte aber dann eher in die Pluginfoku. In dem Thread hier versteht eh keiner mehr etwas außer euch.

Mfg Stefan

cinfo · 15. März 2021

Hi,

wichtig finde ich das der VDR-2.4.6 MCLI-Patch (5) mit in das Git von pbiering

kommt, denn sonst wäre das MCLI-Plugin aus dem GIT nicht nutzbar.

Auch sollte man noch einmal prüfen ob in der Version 0.9.6pre4 auch alle Patches zu diesem Thema enthalten sind.

Grüße

cinfo

HelmutB · 15. März 2021

In der Version 0.9.6pre4 von pbiering sind alle schlußendlich relevanten Patches und fixes bereits enthalten.

Das sind.

- TriggerCAM gleich nach dem Power-on auch wenn der Startkanal FTA ist um das richtige Datum so schnell wie möglich an das CA-Modul zu übergeben
- DeviceReadyWithCI - damit der VDR erst nach einem abgeschlossenem CAM-Reset auf den Startkanal schaltet

- SkipRetuneOnFirstTuner - damit das mcli-Plugin nicht von sich aus auf Kanal #1 schaltet, da bei einem verschlüsseltetn Kanal hier das CAM noch nicht bereit ist

- NOTIFY_CAM_CHANGE ist deaktiviert, da es sonst zu einer Überlagerungen mit dem Programm-OSD kommt

Das ist auch alles als default eingestellt, man muss keine Optionen in der debugmask mitgeben - außer man will das Verhalten umkehren

Code: logging.h

// hidden test options
#define DEBUG_BIT_Action_RetuneOnFirstTuner    0x1000  // retune if the first tuner is found (cPluginMcli::Action)
#define DEBUG_BIT_recv_ts_func_NO_LOGRATELIMIT 0x2000  // disable rate limiter Mcli::recv_ts_func
#define DEBUG_BIT_Action_SkipTriggerCam        0x4000  // skip trigger CAM initialization, even if the first tuning is for a FTA program (cMcliDevice)

Das das mcli-Plugin immer die automatisch Pid 0 aktiviert stört offensichtlich nicht und wurde belassen.

Der vdr-2.4.6.mcli5.patch ist eigentlich nur erforderlich, wenn man mit dem Netceiver auch verschlüsselte Programme sehen will. Ohne CAM muß der VDR nicht gepatcht werden.

LG Helmut

gggggg · 15. März 2021

Danke,

- war da nicht noch x8000 zum Anwählen des 1. Kanals in der channels (wozu auch immer das jemals gut war) ?

- bringt aus deiner Sicht das CA=11 eig. etwas ?

pbrb · 16. März 2021

wenn der so früh im mcli::PreInit stoppt, dann findet er das Netzwerk-Interface nicht. Hab eben den Code um entsprechende esyslog/dsyslog erweitert, dann sollte das sichtbar werden.

/proc/net/if_inet6 kann nicht geöffnet werden
das angegebene Device steht da nicht drin

Ohne Link kann gut sein, daß der Kernel IPv6 auf dem Interface nicht hochfährt.

-> das vdr-Startup-Script braucht einen Check, ob der Netceiver schon erreichbar ist.

Beispiel-Code wäre hier zu finden:

https://github.com/pbiering/Re…n/sbin/reelbox-control.sh

Option: setup_netceiver <interface>

cinfo · 16. März 2021

Zitat von pbrb

wenn der so früh im mcli::PreInit stoppt, dann findet er das Netzwerk-Interface nicht. Hab eben den Code um entsprechende esyslog/dsyslog erweitert, dann sollte das sichtbar werden.

/proc/net/if_inet6 kann nicht geöffnet werden

das angegebene Device steht da nicht drin

Ohne Link kann gut sein, daß der Kernel IPv6 auf dem Interface nicht hochfährt.

anbei zum Testen

cinfo

gggggg · 16. März 2021

Sorry da war noch die Original interfaces drin... danke für die Änderung, die teste ich morgen ... sonst gefährde ich den waf noch mhr

Mit der statischen IP crasht er nicht braucht aber rel. lange

1 Was mit aufgefallen ist:

Code

Mar 16 19:39:59 BM2LTS-N64native-MCLI rc.local[1595]: Error resolving ntp.ubuntu.com: System error (-11)
Mar 16 19:39:59 BM2LTS-N64native-MCLI rc.local[1595]: 16 Mar 19:39:59 ntpdate[1595]: Can't find host ntp.ubuntu.com: System error (-11)
Mar 16 19:39:59 BM2LTS-N64native-MCLI rc.local[1595]: 16 Mar 19:39:59 ntpdate[1595]: no servers can be used, exiting
Mar 16 19:39:59 BM2LTS-N64native-MCLI systemd[1]: rc-local.service: Control process exited, code=exited, status=1/FAILURE
Mar 16 19:39:59 BM2LTS-N64native-MCLI systemd[1]: rc-local.service: Failed with result 'exit-code'.
Mar 16 19:39:59 BM2LTS-N64native-MCLI systemd[1]: Failed to start /etc/rc.local Compatibility.
Mar 16 19:39:59 BM2LTS-N64native-MCLI systemd[1]: Starting Hold until boot process finishes up...

2 was dauert hier 40s:

Code

Mar 16 19:39:09 BM2LTS-N64native-MCLI systemd[1]: systemd-fsckd.service: Succeeded.
Mar 16 19:39:48 BM2LTS-N64native-MCLI systemd-networkd[386]: eth0: DHCPv4 address 10.75.25.22/24 via 10.75.25.1

Meine ext/network/interfaces

Code

auto eth0
#iface eth0 inet dhcp
iface eth0 inet static
address 10.75.25.22
netmask 255.255.0.0
gateway 10.75.25.1

auto eth0.2
#iface eth0.2 inet dhcp
iface eth0.2 inet manual

utiltiy · 16. März 2021

Zu 2, Filesystemcheck, einfach nach fsck mal googeln.

HelmutB · 16. März 2021

Beim Durchlesen deines vorletzten Commit auf github ist mir aufgefallen, das es durch die TriggerCam-Option ohne eingestecktem Modul und ohne --cam-disable in SetChannelDevice() immer Fehermeldungen geben müsste. Stimmt das, ode ist es nur ein Trugschluß von mir?

Im Anhang auf jedefall ein Patch für dein mcli-0.9.6_pre5 mit einigen kleineren Anpassungen dazu.

Deinen cam-disable Commit habe ich auch etwas vereinfacht, indem ich gleich in ProcessArgs() das DEBUG_BIT_Action_SkipTriggerCam Bit in m_debugmask entsprechend setzte. Damit entfallen später ein paar Überprüfungen.

LG helmut

HelmutB · 16. März 2021

Zitat von gggggg

- war da nicht noch x8000 zum Anwählen des 1. Kanals in der channels (wozu auch immer das jemals gut war) ?

- bringt aus deiner Sicht das CA=11 eig. etwas ?

0x8000 war nur der Versuch, die Pid 0 für das CAM-Triggern zu verwenden. Das ging aber nicht und wurde daher wieder enfernt.

CA 11 (=0x11) oder 12 (=0x12) ist meiner Meinung nur erforderlch, wenn beide CI-Slots verwendet werden und einzelne Programme dem richtigen Slot zugeordnet werden sollen. Mit nur einem Modul gibt es ja keine große Auswahl, daher wird es auch nichts bringen.

LG Helmut

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

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema