Recording-Hook "before" ist nicht wirklich before, oder?

  • Hi!


    Ich versuche gerade folgendes zu lösen:
    Ein yaVDR-Server mit einer "festen" S2-Karte und einem per Netzwerk gemountetem Sundtek-S2-Stick.


    Der Sundtek-S2-Stick hängt an einem Raspberry Pi in einem etwas "unfreundlichem" Klima unter dem Dach. Den Stick will ich wegen der Wärme eigentlich nur aktiv haben, wenn er wirklich gebraucht wird, der wird schon unter normalen Umständen selbst ziemlich heiss. Sprich der soll nur aktiv sein, wenn die interne Karte schon beschäftigt ist.
    Dank dem Dynamite-Plugin und dem wirklich guten Treiber von Sundtek kann ich den Stick dem VDR im Betrieb beliebig unterjubeln und auch wieder wegnehmen.


    Ich habe mir also zwei scripte gebastelt für das mounten des S2-Sticks und das unmounten.
    Wegen der festen S2-Karte im Server muss das mount-script für den Stick laufen, wenn bereits eine Aufnahme aktiv ist und eine zweite gestartet werden soll.
    -> Lösung recording-hook before benutzen.
    Das geht aber leider nur, wenn noch ein Empfänger frei ist ... nur dann läuft das recording an und der recording-hook wird aufgerufen ... das ist imho für "before" zu spät und für meinen Zweck sowieso :)


    Ganz genau kenne ich die Interna vom VDR natürlich nicht, aber sollte der recording-hook "before" nicht in dem Augenblick aufgerufen werden, wo der Timer auf is_pending=true gesetzt wird? (was vermutlich passiert bevor versucht wird die Aufnahme tatsächlich zu starten und auf einen Empfänger zu legen... oder liege ich falsch?)
    ... zumal ich gerade gesehen habe, dass es neben der Doku "before, after und edited" noch den hook "started" gibt.


    Dieses "Henne-Ei-Problem" könnte man mit einer while-sleep-Schleife sicher auch lösen, die aktiv wird sobal die interne Karte aufzeichnet ... aber eigentlich mag ich es immer nicht ein Computer mit sowas "nutzlosem" wie minütlichen Checkschleifen zu beschäftigen.


    Also: Ist der "before"-hook so wie er ist wirklich richtig eingehangen, oder war das mal anders gedacht oder bin ich doch völlig falsch?

  • Ich denke, die hooks sollen aufgerufen werden, wenn wirklich Aufnahmen passieren. Einmal vor dem Start, dann, nachdem das Verzeichnis angelegt wurde und noch mal am Ende. Außerdem dann noch beim Löschen.


    Du brauchst eigentlich eine Timerkonflikterkennung. epgsearch macht sowas, ich weiß nur nicht, wie gut sich das mit einem Script auswerten lässt. Und epgsearch bietet da, glaube ich, auch keinen hook. Eine schöne Konflikterkennung wünsche ich mir schon länger für den vdr-core, hatte aber bisher nie Zeit, mich darin zu versuchen.


    Lars

  • Das hat mir keine Ruhe gelassen ... und ich hab mal was gebastelt:


    Ein nodejs-script, das die timers.conf überwacht und Aktivität entwickelt, wenn die Datei vom vdr (oder wem auch immer) angefasst wurde.
    Da der vdr die timers.conf bei Start und Ende einer Aufnahme anpackt, habe ich damit einen "echten" before recording_hook und einen Einstieg, um den Sundtek-Reciever zu mounten, wenn er gebraucht wird und später wieder abzuschalten.


    Das script kann vermutlich ziemlich einfach modifiziert werden, um timer-Konflikte rauszuwerfen und einen anderen trigger bekommen.


    Nodejs habe ich genommen, weil es event basiert ist - also den Trigger mitbringt, es die json-Objekte der restful api nativ versteht und http.gets schön einfach gehalten werden können.


    Möglicherweise hilft das script ja dem einen oder anderen mit einer ähnlichen Problemstellung.


    Achtung! ... ich bin kein Programmierer und schuster sowas nur zusammen - vieles geht sicher "kürzer" und "besser" ... nur keine Scheu ... das Script kann natürlich nach Wunsch verändert werden.


  • Beim Testen heute habe ich noch ein Problem gefunden ... timing ... das script ist schneller als der vdr ...


    Wenn zwei timer gleichzeitig anlaufen, packt der vdr die timers.conf auch zweimal an; sind ja auch zwei events.
    Leider bekam das script nur die erste neue Aufzeichnung mit, da der Zugriff auf die restful api "zu schnell" war und schaltet entsprechend den zusätzlichen reciever bei Bedarf nicht ein.


    Lösung: Einfach mal 15 sekunden warten nachdem die timers.conf angefasst wurde und dann starten.


    Änderungen im script sind eingetragen.

Jetzt mitmachen!

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