VDR startet mit vdr-plugin-mcli nicht (ERROR: invalid primary device number: 1)

  • Es geht um einen VDR der als reines "Headless-System" laufen soll. Keine Ausgabe. Allerdings auch keine "physikalischen" Tuner direkt am Server. Die Tuner sollen von einem alten NetCeiver (vollbestückt mit 6 DVB-S2 Tunern) kommen.


    Ich habe das bereits mit minisatip und vdr-plugin-satip laufen, würde aber gerne alternativ (und sei es nur zum Vergleich) die Option haben auch ohne minisatip direkt vom VDR zum NetCeiver zu verbinden.


    Aktuell ist VDR und Plugins folgendermaßen konfiguriert:

    Code
    $ vdr --showargs
    --chartab=ISO-8859-15
    --grab=/tmp
    --shutdown=/usr/lib/vdr/bin/shutdown-wrapper
    --video=/mnt/hdd/vdr-recordings/video
    --watchdog=90
    --plugin=mcli --ifname enp1s0u2 --debugmask 0xFF --netcvupdate-use-lftp
    --plugin=live
    --plugin=vnsiserver

    Ich habe aber auch schon versucht dem mcli Plugin mitzugeben das 6 DVB-S2 Tuner verfügbar sind. Auch ein zusätzliches Setzen der anderen Empfangsarten auf "0" ändert nichts. Es scheint auch egal zu sein an welcher Stelle ich das mcli Plugin lade. Habe da schon verschiedene Reihenfolgen durch.


    Im Log habe ich dann jeweils:

    Und das ist bereits mit "maximalem Loglevel" und "maximaler Debug-Maske".

    Es sieht für mich so aus als würde der VDR recht früh aufgeben und direkt nach "ERROR invalid primary device" direkt die Plugins wieder entladen.


    Mit dem satip-Plugin geht diese Konstellation auf jeden Fall. Vielleicht kann da jemand einen wesentlichen Unterschied zwischen den Plugins finden. Mir ist nicht bekannt ob es ähnliche Probleme mit Sat>IP auch mal gegeben hat und es da einen Fix im satip Plugin gegeben hat, den man eventuell ins mcli Plugin portieren könnte.

  • direkt vom VDR zum NetCeiver zu verbinden


    "klassisch unter Ubuntu" wäre es nicht so das Du ein mcli.sock benötigst

    /etc/default/mcli

    Code
    NETWORK_INTERFACE="enp1s0u2"
    MCLI_ENABLED="false"
    DVB_C_DEVICES="6"
    DVB_S_DEVICES="6"
    DVB_S2_DEVICES="6"
    DVB_T_DEVICES="6"


    mcli.conf

    --ifname enp1s0u2 --debugmask 0xFF --dvb-s2 6 --mld-reporter-disable --netcvupdate-use-lftp --sock-path /var/tmp/mcli.sock

    (VDR) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA

  • Der Sock wird angelegt. Mir reicht der Default Pfad und der muss nicht extra mitgegeben werden. Ich hätte halt wenigstens irgendeine Art von Fehlermeldung erhofft. Aber so schaut es halt aus als wäre mit dem Plugin alles OK, aber der VDR sieht trotzdem keine Tuner?

  • "headless" -> "no primary device found - using first device!"

    Klingt normal bei headless. Gibt ja kein bevorzugtes Ausgabegerät.


    Code
    Jun 03 23:23:04 vdrserver vdr[29273]: [29273] no DVB device found
    Jun 03 23:23:04 vdrserver vdr[29273]: [29273] initializing plugin: mcli (1.0.0): NetCeiver Client Application

    Klingt auch normal, wenn das mcli Plugin erst nachdem initialisiert, wenn VDR schon längst über fehlende devices gemeckert hat.


    Code
    Jun 03 23:23:04 vdrserver vdr[29273]: [29273] ERROR: invalid primary device number: 1
    Jun 03 23:23:04 vdrserver vdr[29273]: [29273] ERROR: no primary device found - using first device!
    Jun 03 23:23:04 vdrserver vdr[29273]: [29273] ERROR: invalid primary device number: 1

    mcli findet wohl nix. Dann keine devices - Ende.

  • Hi,

    Evtl Ladereihenfolge des Plugins wichtig? Wie beim dynamite-Plugin? Also mcli als Erstes Plugin?

    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • 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...

  • Dann ist aber komisch das es mit satip geht. Was macht das satip Plugin da anders?


    So wie ich das verstanden hab kann der VDR auch "Budget Karten" und damit wahrscheinlich auch Tuner eines Plugins zum "Primary Device" erklären. Ich frage mich jetzt ob die Tuner vom satip Plugin früher beim VDR "angemeldet" werden und so vom VDR als "Primary" nutzbar sind. Vor nächstem Wochenende kann ich das aber nicht prüfen...

  • Zitat

    Der Sock wird angelegt. Mir reicht der Default Pfad und der muss nicht extra mitgegeben werden.

    und der VDR hat auch lese Rechte am mcli.sock?

    (VDR) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA

  • Wenn ich an das Spielen mit minisatip und den Netceiver zurueck denke —> musste ich beim Wechsel auf mcli denn NetCeicer immer einmal stromlos machen — dann lief er wieder sauber mit dem MCLI-Plugin

    (VDR) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA

    Einmal editiert, zuletzt von cinfo ()

  • So, nach etwas Quellcode-Lesen bin ich relativ sicher das Problem gefunden zu haben. Testen kann ich erst wenn ich bei meinem Kumpel bin aber zumindest von der Theorie her macht das jetzt schon mehr Sinn. Meine Intuition, dass es sich um ein Timing-Problem handelt, war auf jeden Fall nicht ganz daneben.


    Ablauf und Ursache des Fehlers

    Die letzte Meldung vom mcli-Plugin ist mcli::Initialize: successful was letztlich vom VDR hier getriggert wird: https://github.com/vdr-project…2a0240751daff6/vdr.c#L814 Wenn man im Quellcode vom mcli Plugin nachschaut, dann wird im "Initialize" erstmal nur grundlegendes vorbereitet. An der Stelle legt mcli noch keine "cDevice"-Instanzen an, exportiert also auch zum VDR hin keine DVB-Empfangsteile.


    Im VDR Quellcode folgt direkt darauf der Block der bei mir den VDR dann mit Fehler abschießt: https://github.com/vdr-project…0751daff6/vdr.c#L817-L847 Dort setzt der VDR sein "primary device" und nimmt das erste verfügbare Device wenn er "nichts besseres findet".


    Erst ein ganzes Stück später ruft der VDR die "Startup"-Methoden der Plugins auf: https://github.com/vdr-project…2a0240751daff6/vdr.c#L868 und erst in dieser legt das mcli-Plugin seine Devices an.


    Schon wenn man diese Abfolge betrachtet kann man annehmen, dass der VDR erwartet, dass "cDevice"-Instanzen im "Initialize" angelegt werden.


    Aussage der offiziellen Doku von Klaus

    Ein Blick auf die "PLUGINS.html" bestätigt die Annahme von oben: https://htmlpreview.github.io/…NS.html#Getting%20started


    Die Doku wird dann später noch etwas direkter wenn es um Devices geht: https://htmlpreview.github.io/…ster/PLUGINS.html#Devices

    A plugin that adds devices to a VDR instance shall call this
    function from its Initialize() function

    to make sure other plugins that may need to have access to all available devices
    will see them in their Start() function.


    Möglicher Fix

    Als mögliche Lösung habe ich mal hier einen Pull Request angelegt. Ich hab etwas gelesen das irgendwann das Initialisieren in "PreInitMcli();" und "InitMcli();" getrennt wurde. Wohl wegen irgendwelcher Fehler in anderen Plugins. Was auch immer das für Fehler waren müsste dann ggf. noch anders umgangen werden, denn die "cDevice"-Instanzen nicht in "Initialize" anzulegen ist nicht konform zur VDR Doku und verhindert in bestimmten Konstellationen den VDR Start.

  • Ich hab auch in zwei anderen Plugins geprüft wie es dort gelöst wurde.


    vdr-plugin-satip: Legt "cDevice"-Instanzen in "Initialize()" an, hat aber für späteres Initialisieren zusätzlicher Dinge noch ein "Start()".

    vdr-plugin-stremdev-client: Nutzt direkt nur "Initialize()" und legt nichtmal ein "Start()" an.

  • 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.

  • vdr-plugin-satip: Legt "cDevice"-Instanzen in "Initialize()" an, hat aber für späteres Initialisieren zusätzlicher Dinge noch ein "Start()".

    satip legt cDevices an, die später dynamisch zu sat>ip tuner nach Bedarf zugeordnet werden. Das könnte hier ebenso eine Lösung sein.

  • Hi,

    Vergleich auch ruhig mal mit dem dynamite-Plugin.

    Das geht ja in dieselbe Richtung wie bei satip, wie von Wirbel beschrieben.

    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Man kann das mal im Hinterkopf halten für den Fall das es sich irgendwann doch rausstellt, dass man Probleme in Zusammenhang mit anderen Plugins gar nicht Herr wird. Aber ohne guten Grund sehe ich jetzt keinen Bedarf das Plugin so umfangreich umzubauen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!