Beiträge von pbrb

    Leicht modifizierter Patch getestet, good-case (siehe unten) funktioniert. Der Grund, wieso ich das in 2021 gesplittet habe, war dieser:


    Code
    commit 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 instantly

    Jetzt 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:


    Beim VDR-Log von oben fehlt

    Code
    mcli version 1.0.0 started

    Vorher kommt übrigens im Log bei mir

    Code
    Jun 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:

    Weiß 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-project…in-am/tree/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/Re…tree/main/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/Re…/src-reelvdr/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.

    Wenn beim Download der File lokal schon existiert kommt folgende Meldung:

    Code
    get: /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/vd…5746259a4853e8f1cef1f6e33


    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.

    aus dem Git bekomme ich diese hier -- wenn eine andere Version benötigt wird dann hänge sie bitte hier an


    Code
    netcvupdate.c
    add various default flags for lftp to avoid unsupported commands on v…
    3 hours ago

    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.

    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":



    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:

    Kann es sein, daß da das "netcvupdate", was auch einen Patch braucht, irgendwie nicht aktualisiert wurde...

    hast Du die mcli.conf Plugin-Optionen erweitert mit "--use-lftp" ?