vdr selbst kompilert und systemd (gelöst)

  • Hallo,

    ich bin dabei ein Problem beim vdr-osd bei mir zu suchen und brauche noch Nachhilfe.
    Habe bei mir ein Ubuntu 20.04 server frisch aufgesetzt und vdr-Paket und vdr-plugins installiert. Soweit so gut, läuft erst mal. Allerdings wird mein OSD zeitweise äusserst langsam, dazu versuche ich nun die Ursache zu suchen. Zuerst hatte ich eine sehr lange channels.conf mit Senderleichen im Verdacht, derzeit sind es eher threads, wenn aufgenommen wird. Mit vdr2.2.0 hab ich das noch nicht beobachtet, aber vielleicht muss ich länger beobachten....


    Hier mal die Fragen :

    vdr2.4.1 und plugins kann ich kompilieren und startet von konsole.

    wenn ich den vdr im Hintergrund starten will (vdr &), dann bleibt der hängen, wenn er kbdremote erzeugt.

    muss ich den vdr für diesen Fall als daemon aufrufen ?


    wenn ich den vdr von konsole starte stimmen alle Pfade.

    wenn ich vdr & starte (habe das kbdremote mal auskommentiert) stimmen die pfade nicht mehr (sucht /usr/share..)

    hat jemand eine Idee, warum das sich unterschiedlich verhält ?


    wenn ich den paket-vdr über systemd starte (z.b. service vdr start) ist alles ok.

    wenn ich den vdr unter /usr/bin durch meinen selbst kompiliert ersetze, dann startet "service vdr start" den vdr, wartet aber auf irgendwas und bricht dann mit timeout den vdr wieder ab.

    Nach meinem Verständnis wird dabei im service-skript ebenfalls nur /usr/bin/vdr aufgerufen.

    Wie übergibt das service-skript dem vdr die Parameter ?

    Anscheinend wird der vdr hier ebenfalls nicht als daemon aufgerufen, aber das Problem mit dem kbdremote taucht nicht auf...

    Was könnte der Grund für den Timeout sein (der vdr startet ja, so etwas wie ein PID-File konnte ich noch nicht finden) ?


    Fragen über Fragen ...

    Ich hoffe, dass jemand Ideen hat.



    Ach so - konkret ist mein Problem, dass das OSD (dvbsddevice) nicht mit dem Bildaufbau hinterherkommt und der vdr nahezu unbedienbar ist. So ein Bildaufbau kann schon mal 5 Sekunden brauchen - schön zeilenweise. Die Hauptschleife läuft dabei ohne Zeitverlust durch, will heißen wenn ich per Fernbedienung 4 Zeilen runtergehe, dann tut sich auf dem OSD erstmal nichts und nach dem nächsten Bildaufbau ist er 4 Zeilen tiefer.

    Manchmal ist aber auch alles wieder schnell. Manchmal ist das OSD nach dem vdr-start schnell, manchmal langsam. Ursache ist halt unklar. CPU-Last bei ca. 13%

    Soweit ich sehen konnte ist das dvbsddevice bei vdr2.2.0 und 2.4.1 identisch.


    Gruß,

    Stefan


    Hardware ist ein Celeron G3900 mit 2x dual receiver und 1x ff-Karte für das OSD und AUsgabe, Aufnahmen gehen auf Festplatte (Softwareraid).

  • Hi,

    Ich fürchte es ist nicht wirklich mehr getestet, SD mit 2.4.1 zu nutzen mit FF.

    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

  • wenn ich den vdr im Hintergrund starten will (vdr &), dann bleibt der hängen, wenn er kbdremote erzeugt.

    muss ich den vdr für diesen Fall als daemon aufrufen ?

    Welchen Sinn hat es denn einen Prozess im Hintergrund zu starten, wenn er von stdin lesen soll? Wenn das nur zum Testen ist und du noch andere Dinge in einer Shell erledigen willst, schalte auf ein anderes TTY oder nimm einen Terminal-Multiplexer wie tmux. Oder du schaltest die kbdremote ab, wenn du sie nicht benötigst.


    wenn ich den vdr unter /usr/bin durch meinen selbst kompiliert ersetze, dann startet "service vdr start" den vdr, wartet aber auf irgendwas und bricht dann mit timeout den vdr wieder ab.

    Das lässt sich aus der vdr.service Zeile 8 ableiten, worauf er wartet:

    Behavior of notify is similar to exec; however, it is expected that the service sends a notification message via sd_notify(3) or an equivalent call when it has finished starting up. systemd will proceed with starting follow-up units after this notification message has been sent. If this option is used, NotifyAccess= (see below) should be set to open access to the notification socket provided by systemd. If NotifyAccess= is missing or set to none, it will be forcibly set to main. Note that currently Type=notify will not work if used in combination with PrivateNetwork=yes.

    Also muss der VDR mit Unterstützung für sd_notify kompiliert werden (vgl. https://projects.vdr-developer…/Make.config.template#n91 im Template für die Make.config) - wobei mir nicht klar ist, warum du nicht gleich die Quellen für das VDR-Paket nutzt, wenn du schon die Systemd-Unit daraus verwenden willst.

    Wie übergibt das service-skript dem vdr die Parameter ?

    Gar nicht, der VDR liest die Konfiguration selbstständig aus dem ARGSDIR - das sollte wie in der

    /usr/share/doc/vdr/README.Debian.gz bzw. https://www.yavdr.org/documentation/0.6/de/ch01s06.html beschrieben funktionieren.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ach so - konkret ist mein Problem, dass das OSD (dvbsddevice) nicht mit dem Bildaufbau hinterherkommt und der vdr nahezu unbedienbar ist. So ein Bildaufbau kann schon mal 5 Sekunden brauchen - schön zeilenweise.

    Welchen Skin nutzt du denn? Die Bandbreite für das OSD ist bei den FF-Karten ja beschränkt, so dass man da animierten OSD-Inhalte wie Laufschriften eher nicht haben will.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Da man die meisten Programme im Hintergrund starten kann, hatte ich erst mal keine Probleme erwartet, da der VDR von systemd oder init ja auch als Hintergrundprozess benutzt wird - na ja zumindest früher gab es dafür ein eigenes Terminal.


    Die Frage zielte gerade darauf ab, ob das Flag -d genau dafür gedacht ist. Es schaltet kbdremote ab, aber ich kann nicht absehen, was es noch bewirkt.

    Welchen Sinn hat es denn einen Prozess im Hintergrund zu starten, wenn er von stdin lesen soll? Wenn das nur zum Testen ist und du noch andere Dinge in einer Shell erledigen willst, schalte auf ein anderes TTY oder nimm einen Terminal-Multiplexer wie tmux. Oder du schaltest die kbdremote ab, wenn du sie nicht benötigst.



    Das lässt sich aus der vdr.service Zeile 8 ableiten, worauf er wartet:

    Also muss der VDR mit Unterstützung für sd_notify kompiliert werden (vgl. https://projects.vdr-developer…/Make.config.template#n91 im Template für die Make.config) - wobei mir nicht klar ist, warum du nicht gleich die Quellen für das VDR-Paket nutzt, wenn du schon die Systemd-Unit daraus verwenden willst.

    Gar nicht, der VDR liest die Konfiguration selbstständig aus dem ARGSDIR - das sollte wie in der

    /usr/share/doc/vdr/README.Debian.gz bzw. https://www.yavdr.org/documentation/0.6/de/ch01s06.html beschrieben funktionieren.


    Gut das füllt schon mal Wissenslücken.

    Hatte schon mal kurz mit Klaus Schmidinger Kontakt wegen dem OSD, und er schlug vor, mit sauberen Sourcen anzufangen, da nicht klar ist, welche Patche beim Paket eingebaut wurden.


    Das mit den Parametern hatte ich vermutet, aber es zu Wissen ist doch gut. Allerdings frage ich mich, warum dann der vdr in der Konsole gestartet die Pfade alle aus den conf-Dateien nimmt, der "vdr &" aber nicht. Ist aber auch nicht wichtig...

  • Welchen Skin nutzt du denn? Die Bandbreite für das OSD ist bei den FF-Karten ja beschränkt, so dass man da animierten OSD-Inhalte wie Laufschriften eher nicht haben will.

    Skin ist LCARS.

    Dürfte eher nicht daran liegen, da VDR2.2.0 mit gleichem Skin das Problem nicht hat. Bei beiden Versionen schein dvbsddevice2.2.0 verwendet zu werden, somit dürfte das plugin auch nicht die Ursache sein.

    Andere Plugins sind nicht aktiv, bzw. ändern nichts, wenn ich sie aktiviere.


    systemd hatte ich als startvariante gewählt, da ich eventuelle Unterschiede beim vdr-start ausschliessen wollte. Es hilft ja auch nichts, wenn es direkt gestartet laufen würde - ich brauche ja den Fehlerfall. Der ist noch nicht reproduzierbar. Mal ist es nen halben Tag alles ok, dann geht wieder gar nichts, ich werde mal mehrere Aufnahmen starten und sehen, ob es daher kommt.

  • Ohne jetzt alles gelesen zu haben, hast Du beim selbst kompilieren SDNOTIFY auf 1 (Make.config) gesetzt, damit vdr mit systemd läuft?

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB