{2026} BM²LTS-v4.6.* - > DD-NET / EXIP / NetCeiver

Ja 3.32 in 4.5.28 ok

Ich dachte solange jojo61 nicht auf mein Posting reagiert bringt das nichts.

Ich würde gerne auf seine Anweisungen warten, damit ich es nicht x fach mache. Leider war sein letzter Login am 19.10.

Das log hängt an meinem Post und ich hab ihn pers. angeschrieben ... und das nächste Mal poste ich es nicht hier sondern unter Plugins.

Wenn es OK läuft (3.32) kommt diese Meldung nicht:
Oct 25 17:47:33 BM2LTS-MC vdr: Cannot create buffer source

Einstweilen Vorschlag für Änderung in usr\sbin\grub-set
Da aktuell immer die "Alte" Kernel Commandline v. letzten boot statt der gerade neu erstellten ausgegeben wird
Also statt              sudo dmesg | grep edid ein   cat /boot/grub/grub.cfg | grep video=

Ja ist getestet.

danke, schaut auf 1. Antesten gut aus !

Kannst du mal nachsehen ob du im Image auch diese Files hast- Falls ja bitte löschen: /opt/vdr/conf.d.native.mcli
40-satip.conf
40-satip.conf.all

Zum Prob, dass mcli ohne Netzwerk nach 3min. den vdr stoppt (die Idee mit dem IPTV funkt erst wenn das gelöst ist):

https://github.com/pbiering/vdr-p…b/master/mcli.c
#define IFACE_WATCH_TIMEOUT 180
#define IFACE_WATCH_STEP 5

Nach Ablauf der 3min kommt dann in Zeile 200 return=false und ich vermute der vdr stoppt danach.

Ev. reicht es in Zeile 200 = true zu retournieren.
cinfo könntest du bitte mcli.c mit dieser Änderung bauen.

DAnke,

Dec 8 17:56:23 BM2LTS-MC vdr: [1431] initializing plugin: mcli (1.0.1B): NetCeiver Client Application
Dec 8 17:56:23 BM2LTS-MC vdr: [1431] mcli::Initialize: called
Dec 8 17:56:23 BM2LTS-MC vdr: [1431] mcli::PreInitMcli: called with m_cmd.iface='eth0.2' builtin watch-timeout=220 watch-step=3
Dec 8 17:56:23 BM2LTS-MC vdr: [1460] video directory scanner thread started (pid=1431, tid=1460, prio=low)
Dec 8 17:56:23 BM2LTS-MC vdr: [1431] mcli::PreInitMcli: can't find specified device 'eth0.2' in /proc/net/if_inet6 (after 0 of 220 sec / wait next 3 sec)
Dec 8 17:56:26 BM2LTS-MC vdr: [1431] mcli::PreInitMcli: can't find specified device 'eth0.2' in /proc/net/if_inet6 (after 3 of 220 sec / wait next 3 sec)

aber hast du das timeout auf 220 gesetzt ? Zum Testen wäre es hilfreich das eher auf 60s (schade dass wir dazu keinen Parameter haben) zu setzten

So einfach wie ich hoffte ist es wohl nicht, weil der vdr stürtzt nach den 220s ab:
Dec 8 18:10:34 BM2LTS-MC vdr: [1431] mcli::PreInitMcli: can't find specified device 'eth0.2' in /proc/net/if_inet6 (after 220 sec)
Dec 8 18:10:34 BM2LTS-MC vdr: [1431] new device number 1 (card index 1)
Dec 8 18:10:34 BM2LTS-MC vdr: [1431] cTimeMs: using monotonic clock (resolution is 1 ns)
Dec 8 18:10:34 BM2LTS-MC vdr: [1999] device 1 section handler thread started (pid=1431, tid=1999, prio=low)
Dec 8 18:10:34 BM2LTS-MC vdr: [1431] mcli::cMcliDevice: USING VDR PACKET BUFFER
Dec 8 18:10:34 BM2LTS-MC kernel: [ 227.858319] vdr[1431]: segfault at 8 ip 00007f9210556c07 sp 00007ffee7ce8180 error 6 in libnetceiver.so.1.0.0[8c07,7f9210552000+10000] likely on CPU 3 (core 1, socket 0)
Dec 8 18:10:34 BM2LTS-MC kernel: [ 227.858340] Code: df 03 01 00 48 89 68 f8 4c 89 e7 48 89 43 20 48 89 43 18 e8 0b c6 ff ff 48 8b 45 00 48 89 6b 08 4c 89 e7 48 89 5d 00 48 89 03 <48> 89 58 08 e8 a0 c6 ff ff 48 89 d8 5b 5d 41 5c c3 e8 c3 c3 ff ff
Dec 8 18:10:34 BM2LTS-MC systemd[1]: vdr.service: Main process exited, code=killed, status=11/SEGV

So einfach ist die Sache nicht....ein "return true;" resultiert in einem erfolgreichen "cPluginMcli::Initialize".

Welches Verhalten wollt Ihr denn? Daß der vdr läuft, obwohl "mcli" nicht initialisiert werden konnte? Ein "lazy" wird vom VDR nicht unterstützt.

Option 1: man prüft vor Start des VDRs, ob die Schnittstelle funktioniert, wenn nicht, dann das Plugin gar nicht aktivieren.

Option 2: neue Option einbauen "ignore-if-problem", man merkt sich den cPluginMcli::Initialize den Fehlerstatus, gibt aber trotzdem "true" zurück, aber bei "cPluginMcli::Start" wird das "gemerkte" geprüft und das Plugin gibt entweder hier dann "false" zurück....wenn einem der VDR das immer noch übel nimmt, dann weiter vorarbeiten und z.B. bei "cPluginMcli::Action" einfach nichts tun.

Und bzgl. der aktuell hartcodierten Timeouts...es sollte ein leichtes sein, da entsprechende Optionen hinzuzufügen: cPluginMcli::ProcessArgs und die defines damit zu ersetzen

Hoffe, das hilft Euch weiter, viel Erfolg....wenn Ihr dann eine Patch habt, der Euch genügt, prüf ich den gerne und merge den nach Upstream.

Danke trotzdem, aber belasse das mcli Timeout auf den 180s (3 Min). Das ist die Zeit die max. auf das Netzwerk gewartet wird.

Danke pbrb für die Idee das mcli im Falle dessen wenn kein Netzw da ist nicht zu laden.

Falls es eure Zeit mal erlaubt, wäre es sicher sinnvoll die Parameter über den mcli.conf veränderbar zu machen und nat. im Falle des fehlenden Netzwerks nicht einfach den vdr zum Beenden zu zwingen.