Ich hab da mich mal reingegraben und imho paßt was nicht im aktuellen minisatip -> schaut hier mal: https://github.com/catalinii/minisatip/discussions/1282
Posts by pbrb
-
-
Leicht modifizierter Patch getestet, good-case (siehe unten) funktioniert. Der Grund, wieso ich das in 2021 gesplittet habe, war dieser:
Codecommit a777cc5a68bc31f21c33561440dd20462c973542 Author: Peter Bieringer <pb@bieringer.de> Date: Thu Mar 11 08:01:12 2021 +0100 introduce PreInit and PostExit to avoid crashes in case of other plugins have fatal issues and VDR has to stop instantlyJetzt müßte man mal einen "other plugin fatal issue" Fall provozieren und prüfen, ob dann VDR immer noch crasht. Wenn ja, dann mcli verbessern, wenn man die Crash-Ursache genau gefunden hat.
BTW: dieser Patch bewirkt nun auch, daß im LCARS Theme die Tuner nun mit 1 anfangen und nicht mit 2...softhhdevice ist dafür auf 9 gerutscht, war vorher wohl 1.
-
also hier im normalen VDR schaut das Log bzgl. "mcli" eigentlich wie folgt aus:
Code
Display MoreJun 04 20:45:17 reelbox-ng vdr[1317]: [1317] loading plugin: /usr/lib64/vdr/libvdr-mcli.so.2.6.3 Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli::cMcliDeviceList: create device list Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] initializing plugin: mcli (1.0.0): NetCeiver Client Application Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli::Initialize: called Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli::PreInitMcli: called with m_cmd.iface='eth1' builtin watch-timeout=180 watch-step=5 Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli::PreInitMcli: found specified device 'eth1' in /proc/net/if_inet6 (after 0 sec) Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli::Initialize: successful Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] starting plugin: mcli Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli version 1.0.0 started Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli::cMcliDevice: USING VDR PACKET BUFFER Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli::cMcliDevice: USING VDR PACKET BUFFER Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli::cMcliDevice: USING VDR PACKET BUFFER Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli::cMcliDevice: USING VDR PACKET BUFFER Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli::cMcliDevice: USING VDR PACKET BUFFER Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli::cMcliDevice: USING VDR PACKET BUFFER Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli::cMcliDevice: USING VDR PACKET BUFFER Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli::cMcliDevice: USING VDR PACKET BUFFER Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] mcli::Start: successful Jun 04 20:45:19 reelbox-ng vdr[1317]: [1333] mcli::Action: Add CAMs from NetCeiver: [fe80::208:54ff:fe**:****] -> 1 Jun 04 20:45:19 reelbox-ng vdr[1317]: [1333] mcli::Action: Add Tuner(#0): Philips TDA10023 DVB-C [fe80::208:54ff:fe**:****:0100], Type 1 @ 1 Jun 04 20:45:19 reelbox-ng vdr[1317]: [1333] mcli::Action: Add Tuner(#1): Philips TDA10023 DVB-C [fe80::208:54ff:fe**:****:0102], Type 1 @ 1 Jun 04 20:45:19 reelbox-ng vdr[1317]: [1333] mcli::Action: Add Tuner(#2): Philips TDA10023 DVB-C [fe80::208:54ff:fe**:****:0104], Type 1 @ 1 Jun 04 20:45:20 reelbox-ng runvdr[1317]: mcli::recv_ts_func: Discontinuity on receiver 0x5615b249**** for pid 5101: 3->5 at pos 0/7 Jun 04 20:45:20 reelbox-ng vdr[1317]: [1350] mcli::handle_ten: m_chan.Name='Das Erste HD' m_chan.Number=1: Status:03 Strength:0x0000 SNR:0x0000 BER:0x0000 Jun 04 20:45:20 reelbox-ng vdr[1317]: [1364] mcli: sections assembler thread started (pid=1317, tid=1364, prio=high)Beim VDR-Log von oben fehlt
Vorher kommt übrigens im Log bei mir
CodeJun 04 20:45:17 reelbox-ng vdr[1317]: [1317] initializing plugin: softhddevice (1.10.0): Ein Software und GPU emulieres UHD-Gerät Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] new device number 1 (card index 1) ... Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] setting primary device to 1 Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] assuming manual start of VDR Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] setting current skin to "lcars" Jun 04 20:45:17 reelbox-ng vdr[1317]: [1317] loading /var/lib/vdr/data/themes/lcars-default.theme-> "cPluginMcli::Start" aus mcli.c wird gar nicht aufgerufen, d.h. der VDR hat vorher schon "beschlossen", wieder zu stoppen => meineserachtens liegt das aber nicht am "mcli"-Plugin", sondern daran, daß er kein primary device hat für die Ausgabe, aber eins will...
-
Nein, das Paket nutzt auch nur das SysV-Init Skript aus dem Debianpaket - mein Vorschlag wäre sowas:
Code
Display More# /etc/systemd/system/vdradmin-am.service [Unit] Description=vdradmin-am a SVDRP-based VDR frontend written in Perl Documentation=man:vdradmind(8) After=network-online.target Wants=network-online.target [Service] User=vdradmin-am Group=vdradmin-am Type=simple ExecStart=/usr/bin/vdradmind -n --ipv6 [Install] WantedBy=multi-user.targetWeiß jemand, warum da explizit ein nice-Wert für den Prozess gesetzt wird? Ist das noch ein Problem bei den heutzutage von Ubuntu unterstützten CPUs?
hier gibt's ein unit-File, was unter Fedora Linux funktioniert:
https://github.com/vdr-projects/v…/master/contrib"nice" ist immer noch eine gute Wahl für Daemons, die gerne mal länger Resourcen fressen, um den Rest vom System nicht zu beeinflussen.
-
gggggg : leider kann ich dazu nichts (mehr) beisteuern, habe die eHD aktuell schlafen gelegt (in der Test-Reelbox ist sie noch drin...) - Hab mal vor einiger Zeit rumgefragt, wer denn eine lauffähige Buildumgebung für das MIPS eHD-Image hat...leider nichts erfahren.
Die Images, die mir über den Weg gelaufen sind, habe ich hier abgespeichert:
https://github.com/pbiering/ReelB…bin-reelvdr/eHD
Einzig das Linux-Kernel-Modul habe ich mal mit etlichen Debug-Optionen versehen und 64-bit Kernel-Support eingebaut.
https://github.com/pbiering/ReelB…dr/utils/hdshm3
Falls aber auf Linux-Kernel-Modulseite nichts zu sehen ist, müßte man mal ins MIPS-Image Debug-Optionen reinstreuen.
Ggf. findet man aber schon Hinweise, wenn man sich per Telnet auf eHD einloggt und mal da im Kernel Log (dmesg) guckt...vielleicht sind irgendwelche Puffer zu klein.
-
0.9.7 released: https://github.com/vdr-projects/vdr-plugin-mcli/releases
Hoffe, daß da keine anderen Patches mehr fehlen...sonst gibt's halt 0.9.7.1
-
letzter Feinschliff:
wenn --netcvupdate-enable-debug NICHT gesetzt ist, sollte auch die Ausgabe des Datentransfers weg sein:
die FTP-Ausgabe wird mit "-q" unterdrückt....eingebaut in cam_menu.c:
-
Wenn beim Download der File lokal schon existiert kommt folgende Meldung:
Codeget: /root/netceiver.conf: Datei existiert bereits und xfer:clobber ist nicht gesetzt ---- Schließe die Datenverbindung ---- Schließe den Kontroll - Socket Download failed (ret=256)Das war aber denke ich schon immer so !
Kann auch sein, daß der ursprüngliche "ftp" client da einfach gnadenloser war und die lokale Datei überschrieben hat ohne zu Meckern.
Hab mal bei "lftp" den "get" um Option "-a" erweitert, damit meckert nix mehr.
https://github.com/pbiering/vdr-p…53e8f1cef1f6e33
Bitte mal final testen, dann merge ich den Branch nach "master".
Ist sonst noch was offen? Weil sonst erstelle ich einen Release.
-
"netcvupdate" ist aber nicht reinkompiliert ins Plugin (wäre ja sonst eine Art Bibliotheksaufruf notwendig), sondern wird als externes Kommando aufgerufen durch "SystemExec(c)" mit dem vorher zusammenstellten String "c"....und Ihr wolltet da die Zusatzoption "-o" reinschmuggeln....das hat nicht geklappt (war fast erwartbar).
Dewegen hat "netcvupdate" jetzt 2 neue Schalter, die im String "c" entsprechend gesetzt werden.
Alles, was man sieht in
dsyslog("EXEC1 %s", (const char *)c);
dsyslog("EXEC2 %s", (const char *)c);
wird aufgerufen als externes Kommando.Die Kette ist also: MCLI-Plugin-Menü -> Triggert Aktion -> ruft "netcvupdate" mit Optionen auf -> das wiederum ruft den ftp-Client (auch als externes Kommando) auf mit einem zusammengestellten Script.
Man könnte das natürlich alles mit einer Art "libftp" all-in-one machen...aber der Code ist halt historisch so zusammen verknüpft.
-
die paßt...aber gggggg benötigt die Binaries irgendwie, bisher war im tar.bz2 wohl immer nur das Plugin drin und nicht die 3 externen Binaries: netcvdiag, netcvlogview, netcvupdate -> mindestens "netcvupdate" muß aktualisiert werden.
-
Zur "neuesten" Plugin-Version brauchst Du auch das neueste "netcvupdate"...sonst kommst nicht weiter.
Anbei mal statisch kompilierte Versionen, aber bitte nur zum Testen verwenden...mußt das aktuell genutzte "netcvupdate" überschreiben (und natürlich "-static" entfernen...
-
der "make" eines Plugins wird ohne entsprechende vdr-devel nicht gehen...da braucht's schon bisserl Vorbereitung.
Aber der Branch "lftp-fixes" müßte eigentlich nun funktionieren, wenn "netcvupdate" auch auf dem Stand vom Branch ist, weil das ist Voraussetzung, daß "-o" aktiv wird.
Und daß sich "-o" nicht via cam_menu.c "reinschmuggeln" ließ, dann daran liegen, weil ein implizites Escaping der Argumente beim Aufruf von "netcvupdate" ggf. passiert...d.h. eine Zusatzoption für's finale FTP-Script geht über diesen Weg nicht rein.
-
funktioniert auch mit "Pfad":
Code
Display More./mcast/tool/netcvupdate -n -e -i fe80::208:54ff:fe**:**** -d enp4s0 -U /tmp/netceiver.conf INFO : enable options for FTP client 'lftp' DEBUG : enable debugging UUID fe80::208:54ff:fe**:****: Uploading /tmp/netceiver.conf ... DEBUG : execute FTP command: lftp --norc -d DEBUG : execute FTP script ------ set ftp:use-site-utime off set ftp:use-site-utime2 off set ftp:use-feat off set ftp:ssl-allow false open fe80::208:54ff:fe**:****%enp4s0 user root root cd /mmc/etc/ put /tmp/netceiver.conf -o netceiver.conf quit ------Die Version beruht nun auf letztem Commit, der setzt bei "lftp" paar Flags, um nicht unterstützte Kommands auf Serverseite gar nicht erst zu versuchen.
-
Also hier funktioniert das:
Code
Display More./mcast/tool/netcvupdate -n -e -i fe80::208:54ff:fe**:**** -d enp4s0 -U netceiver.conf INFO : enable options for FTP client 'lftp' DEBUG : enable debugging UUID fe80::208:54ff:fe**:****: Uploading netceiver.conf ... DEBUG : execute FTP command: lftp --norc -d DEBUG : execute FTP script ------ open fe80::208:54ff:fe**:****%enp4s0 user root root cd /mmc/etc/ put netceiver.conf -o netceiver.conf quit ------ ...Kann es sein, daß da das "netcvupdate", was auch einen Patch braucht, irgendwie nicht aktualisiert wurde...
-
Kannst Du mal die Debug-Logzeilen mit EXEC1 und EXEC2 schicken?
-
sorry für das recht interaktive "DevOps"...das Option-Handing in netcvupdate ist ja leider etwas sehr angestaubt...habe cam_menu.c grad eben gefixt und die Optionen an den Anfang verschoben.
-
-e ist nun aktivierbar, aber für den Inhalt von (vdr-)mcli.conf ist der Endanwender zuständig...
Braucht wohl in etwa folgende Erweiterung:
PLUGIN_OPTIONS="$PLUGIN_OPTIONS --netcvupdate-enable-debug --netcvupdate-use-lftp"
-
Versucht aktualisierten Diff
https://github.com/pbiering/vdr-p…er...lftp-fixes
Plugin kennt jetzt 2 neue Optionen:
- --netcvupdate-enable-debug -> fügt Schalter "-e" dran bei netcvupdate Aufrufe
- --netcvupdate-use-lftp -> fügt Schalter "-n" dran bei netcvupdate Aufrufe
-
Display More
1 Da nutzt es kein lftp weil -q error kommt:
Feb 6 07:55:04 BM2LTSnativeMC vdr: [1977] EXEC1 rm -f /tmp/netceiver.conf; cd /tmp; netcvupdate -i fe80::208:54ff:fe54:b261 -d eth0.2 -D
Feb 6 07:55:04 BM2LTSnativeMC vdr[1980]: UUID fe80::208:54ff:fe54:b261: Downloading netceiver.conf ...
Feb 6 07:55:04 BM2LTSnativeMC vdr[1982]: ftp: q: unknown option
2 Bitte beim Aufruf in allen Zeilen -e einbauen
netcvupdate -e -i fe80::208:54ff:fe54:b261 -d eth0.2 -D
hast Du die mcli.conf Plugin-Optionen erweitert mit "--use-lftp" ?
-
versucht mal folgenden Diff:
https://github.com/pbiering/vdr-p…er...lftp-fixes
damit hat das Plugin eine neue Option "--use-lftp", die sich weiter-"vererbt" auf die Aufrufe von "netcvupdate". Paar Debug-Statements habe ich auch aktiviert.