yavdr frontend detached und shutdown Problem

    Moin,


    mein yavdr hat offenbar das Problem, dass er manchmal nach Timeraufnahmen wohl das Frontend detached, aber nicht herunterfährt. Wenn ich dann morgens merke, dass die Kiste immer noch läuft, setze ich meistens per remote ein Poweroff ab, aber auch der bewirkt nichts. Schalte ich den Beamer ein, sehe ich das yavdr logo mit der Meldung "Frontend detached..." - drücke ich einen Knopf, startet das Frontend auch wieder und erst dann kann ich per remote herunterfahren. Lästige Sache.


    Die Syslog ist im Anhang. Die Verbindungen von der ip .22 sind okay, von dort aus habe ich mehrfach den Remote Befehl per curl abgesetzt, das ist ein Webfront auf meiner FB-TFT.


    Paket-Versionen:


    dmesg:

    Zitat


    die vdr-frontend.log


    Danke für jede Hilfe,
    Tom

    Das ist ja noch ein yaVDR 0.5 - generell ist es so, dass das Frontend-Skript dem VDR ein remo off sendet, damit der nicht mehr auf die Fernbedienung reagiert, wenn das Frontend detached ist - bei jedem wiederholten Shutdown-Versuch schaltet er mit "remo on" die Reaktion auf die Fernbedienung wieder ein, sendet den Power-Key und schaltet die Reaktion auf die Fernbedienung wieder ab: https://github.com/yavdr/yavdr…ddevice-02-script.py#L134 - das passiert allerdings nur, wenn es kein offensichtliches Shutdown-Hindernis gibt.


    Im syslog steht, dass Benutzeraktivität den Shutdown verhindert (Returncode 901 bei der Abfrage über dbus2vdr) - soweit ich das sehen kann, stammt die daher, dass es noch aktive VNSI-Clients im Netzwerk gibt:

    Code
    Sep 25 09:53:11 c3po vdr: [12294] VNSI: Client with ID 229 connected: 192.168.178.22:57054
Sep 25 09:53:11 c3po vdr: [14191] VNSI: cxSocket::read: eof, connection closed
Sep 25 09:53:11 c3po vdr: [12296] VNSI: Client with ID 229 seems to be disconnected, removing from client list
Sep 25 09:53:12 c3po vdr: [12179] connect from 192.168.178.22, port 57053 - accepted
Sep 25 09:53:12 c3po vdr: [12179] lost connection to SVDRP client
Sep 25 09:53:12 c3po vdr: [12179] closing SVDRP connection
Sep 25 09:53:23 c3po vdr-frontend[12376]: vdr not ready for shutdown: 901: 
Sep 25 09:53:40 c3po vdr: [12294] loading /var/lib/vdr/plugins/vnsiserver/allowed_hosts.conf
Sep 25 09:53:40 c3po vdr: [12294] VNSI: Client with ID 230 connected: 192.168.178.22:57238

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    kann gut sein - mehr als apt-get update und dist-upgrade habe ich seit der Installation nicht gemacht, und damit kommt man wohl nicht auf eine 0.6 ...


    Zum Problem: Lese ich das richtig, dass das der Client mit der IP .22 ist ? Auf dem läuft Windows, aber kein Kodi und nach meiner Erkenntnis auch kein VNSI-Client. Allerdings ist das der PC, von dem aus ich den vdr fernbediene. Der öffnet u.a. sockets über 6419 zu dem vdr.


    Kann ich den vdr dazu bringen, dass er offene Verbindungen zu/von der IP .22 einfach ignoriert ?

    Wenn du xvdr und vnsiserver nicht nutzt, kannst du die Plugins deaktivieren. Das Zurücksetzen des Inaktivitätstimeouts durch vnsiserver bei einer vermeintlichen Client-Verbindung müsstest du aus dem Plugin rauspatchen (oder herausfinden, was dein Rechner da genau macht, dass ihn der vnsiserver fälschlicherweise als Client ansieht - denn der verbindet sich ja anscheinend auch auf anderen Ports als dem SVDRP-Port 6419).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Hi, derzeit versuche ich gerade mal wieder, das Problem in den Griff zukriegen. Gemacht habe ich:


    yavdr 0.6 neu installiert, vnsi server plugin deaktiviert, xvdr war sowieso deaktiviert.


    leider besteht das Problem nach wie vor - beim shutdown request kommt:


    Mir ist völlig unklar, wieso .22 als Client angesehen wird. Auf dem Gerät ist kein Kodi oder irgendein vnsi Client, der mir da einfällt. Außerdem ist VNSI-server ja deaktiviert.


    Kann man dem yavdr irgendwie beibringen, dass er diese angebliche Verbindung zum .22 ignoriert ? Irgendwie scheint die ja auch als tot erkannt zu werden, baut sich aber immer wieder mit dem anderen Port auf ?


    Andere Frage: Derzeit fahre ich den Server in der Form runter, dass ich erst einen Reboot sende und dann danach den shutdown sende (sonst klappt das Aufwachen per ACPI nicht). Ich frage dazu per SVDR erst mal, ob irgendeine Aufnahme geplant ist. Kann ich auch irgendwie abfragen, ob der TV eingeschaltet ist ? (Der hängt direkt am hdmi des Servers).

    Zitat von LimpBiz

    Mir ist völlig unklar, wieso .22 als Client angesehen wird. Auf dem Gerät ist kein Kodi oder irgendein vnsi Client, der mir da einfällt. Außerdem ist VNSI-server ja deaktiviert.


    Was ist das für ein Gerät? Kannst du da mal auf dem Gerät nachsehen, welches Programm den Port nutzt?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Was für ein Betriebssystem läuft auf dem Laptop?
    Für Windows könnte man z.B. den Microsoft Message Analyzer nehmen: https://www.microsoft.com/en-u…oad/details.aspx?id=44226
    Unter Linux sollte man mit

    Code
    sudo netstat -taupenc

    weiter kommen (mit einem dahinter gehängten grep kann man dann die Ausgabe noch nach der IP-Adresse des VDR filtern).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Aaaah - ich weiß, jetzt, woran das Problem liegt. Das mit dem Client .22 war eine falsche Spur, hat mit dem gar nichts zu tun.


    Der Shutdown wird bei mir verhindert oder nicht ausgeführt, wenn auf dem TV die berüchtigte Meldung steht: "Frontend detached" - das scheint bei mir häufig der Fall zu sein, wenn eine Timeraufnahme durchgeführt wurde. Wenn ich dann einfach eine Taste auf der FB drücke, ist das Frontend wieder da und dann geht auch der shutdown. Das hatte ich erst gar nicht gemerkt, da mein TV ein Beamer ist - den macht man ja nicht mal eben so an.


    Leider weiß ich nicht, wie ich das in Griff kriegen soll (siehe oben)

    Laut dem weiter oben geposteten Log sieht das für mich so aus, dass das vnsiserver-Plugin den Benutzerinaktivitätstimeout wegen dem Verbindungsversuch der Rechners 192.168.178.22 zurückgesetzt hat, was dann eben den Shutdown verhindert, weil die Abfrage in https://github.com/yavdr/yavdr…ter/usr/bin/frontend#L263 Benutzeraktivität zurückliefert.
    Wenn an der Stelle die Benutzeraktivität ignoriert werden soll, kannst du mal versuchen die Zeile 263 von

    Code
    if shutdown.confirmShutdown():

    in

    Code
    if shutdown.confirmShutdown(True):

    zu ändern. Aber interessanter wäre IMHO, warum es da überhaupt Verbindungsversuche von dem Laptop aus zu vnsiserver gibt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Das probiere ich mal, danke.


    Der Laptop verbindet sich alle paar min mit dem vdr und liest mit svdrp die recordings und timers aus. Damit zeige ich an, was an Aufnahmen gelaufen oder geplant ist - auch wenn der vdr aus ist. Aber das sind ja eigentlich immer nur Anfragen über Port 6419. Außerdem hat das den Shutdown nie unterbunden, zumindest solange das frontend verbunden war.

    Zitat von LimpBiz

    Spricht etwas dagegen, dem vdr prophylaktische jede Stunden per SVDRP einjen REMO ON zu senden ?

    Dass dann ungewollt der VDR mit bedient wird, wenn jemand gerade KODI damit nutzt.

    Zitat von LimpBiz

    Oder kann ich den Zustand irgendwie extern erkennen ?

    Den Status kannst du so abfragen:

    Code
    svdrpsend remo

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Hi LimpBiz,


    hatte gleiches Problem und mache zyklisch per crontab :


    Code
    /usr/bin/svdrpsend "remo on" && sleep 15 && /usr/bin/svdrpsend "HITK Power" > /dev/null 2>&1



    vdrdream

    OctupusNet SATIP Server => VDR-SERVER : i3-4150, 4GB, NVidia GT640 passiv, yaVDR 0.6.1, X10 FB

    Clients : Windows-PC's mit VDR-Zapper, Android-Handys und FireTV mit VDR-Manager (MX-Player) am Smarttvweb Plugin, iPad per Goodplayer am Streamdev-Server Plugin
    in Rente:
    Server/lokaler VDR : AT5IONT-I, 4GB, 2.5" 500GB HD, yavdr 0.5.0a, Mystique SaTiX-S2 V2 CI Dual,TT USB-3600,August DVB-T210 V2.0, Pollin Cyberlink IR Empf.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden