[gelöst][yaVDR 0.5] Frage zum nächtlichen Abgleich des EPG mittel xmltv2vdr

xmltv2vdr setzt die Aufwachzeit 3 Minuten vor der Zeit (Hardcoded), das acpi Shutdownscript gibt per default 5 Minuten dazu, das könnte man ändern.

Aber mit fixes Zeiten ruzufummeln ist der falsche Weg. Hier muss einfach noch die Abfrage für "Active" der Plugins rein, weil die scheint (das würde ich jetzt als erstes prüfen) zu fehlen.
Weil xmltv2vdr braucht solange wie es braucht (ist nicht wiklich vorhersagbar), und danach werden die Suchtimer wieder aktiviert und epgsearch braucht dann auch noch etwas für den Lauf. Also darf der vdr erst runterfahren wenn alle Plugins bei der Abfrage von Active "NULL" zurückgeben.

cu

Dann verhält sich das Plugin aber merkwürdig - der VDR sollte ja sehen, dass er wegen einem ACPI-Wakeup Event geweckt wurde und dann MinEventTimeout warten, bis er den Shutdown einleitet (was steht da im syslog - "assuming manual start" oder "assuming start for acpi-wakeup"?):
https://github.com/yavdr/yavdr…ddevice-02-script.py#L364

Zitat von OleS

Und dann kommt der böse Shutdown (nach 5 Min., da das Frontend nicht aktiv ist - soll ja auch nicht.

Code

dbus2vdr: new message, object /Shutdown, interface de.tvdr.vdr.shutdown, member ConfirmShutdown

Das ist nicht der böse Shutdown, sondern schlicht eine Frage an den VDR ob er, ein Plugin oder ein Shutdown-Hook etwas gegen das Herunterfahren hat.
Wenn das Plugin nicht signalisiert, dass es noch beschäftigt ist, kann ich nichts dafür - evtl. sollte man da - wenn es ein externes Skript gibt - das als Kriterium für einen Shutdown-Hook einbauen.

Zitat von seahawk1986

Wenn das Plugin nicht signalisiert, dass es noch beschäftigt ist

Das tut es ja, deswegen hatte ich jetzt vermutet das diese Abfrage nicht klappt.

cu

Zitat von Keine_Ahnung

Das tut es ja, deswegen hatte ich jetzt vermutet das diese Abfrage nicht klappt.

Also mein Test für ein aktives Plugin, das den Shutdown verhindert ist klassicherweise Streamdev - da liefert dbus2vdr immer den korrekten Antwort-Code 905:

$ vdr-dbus-send /Shutdown shutdown.ConfirmShutdown boolean:true
method return sender=:1.2 -> dest=:1.6 reply_serial=2
   int32 905
   string "some plugin is active"
   int32 0
   string ""

Zitat von https://github.com/yavdr/vdr-plugin-dbus2vdr

Interface "shutdown"
--------------------
- ask vdr if it is ready for shutdown
vdr-dbus-send.sh /Shutdown shutdown.ConfirmShutdown [boolean:true]
possible reply codes:
250: vdr is ready for shutdown
550: vdr is not ready for shutdown (unknown reason)
901: user is active
902: cutter is active
903: recording is active
904: recording is active in the near future
905: some plugin is active
906: some plugin will wakeup vdr in the near future
990: (reply message contains SHUTDOWNCMD)
991: (reply message contains TRY_AGAIN of the shutdown-hooks)
992: (reply message contains ABORT_MESSAGE of the shutdown-hooks)
999: shutdown-hook returned a non-zero exit code

You may shutdown vdr on reply codes 250 and 990.

Alles anzeigen

Zitat von OleS

Code

Mar  2 03:01:52 htpc vdr-frontend[2127]: assuming start for acpi-wakeup

Dann müsste er hier einen Timeout entsprechend dem Brückentimer setzen: https://github.com/yavdr/yavdr…ddevice-02-script.py#L367 - und erst wenn das abgelaufen ist, sollte er nachfragen, ob der VDR herunterfahren will.

Auf welchem Wert steht der Brückentimer denn? Bzw. wenn du es für den Fall abweichend setzen willst, kannst du da einfach in Millisekunden angeben, wie lange er warten soll.

Also bei mir gehts

root@dirk-vdr:~# vdr-dbus-send /Shutdown shutdown.ConfirmShutdown boolean:true
method return sender=:1.7 -> dest=:1.21 reply_serial=2
   int32 250
   string "vdr is ready for shutdown"
   int32 0
   string ""
root@dirk-vdr:~# svdrpsend plug xmltv2vdr updt
220 dirk-vdr SVDRP VideoDiskRecorder 1.6.0-3; Sat Mar  2 10:56:36 2013; UTF-8
250 update started
221 dirk-vdr closing connection
root@dirk-vdr:~# vdr-dbus-send /Shutdown shutdown.ConfirmShutdown boolean:true
method return sender=:1.7 -> dest=:1.23 reply_serial=2
   int32 905
   string "some plugin is active"
   int32 0
   string ""

Und beim automatischen Start (bei mir um 8 Uhr) ist mir noch nie nen Fehler aufgefallen.

Tja, dann scheint das System generell zu passen, also Bug suchen.

Edit: Ach hat sich ja schon gefunden

cu

Zitat von Keine_Ahnung

Edit: Ach hat sich ja schon gefunden

irgendwie komme ich da nicht ganz mit...

OleS: könntest du mal ein komplettes syslog posten? Mit den Schnipseln tu ich mir etwas hart...

Zitat von seahawk1986

irgendwie komme ich da nicht ganz mit...

Die Lösung ist doch das der Runterfahrenversuch kommt bevor das xmltv2vdr Plugin überhaupt anfängt.

Jetzt interessiert mich aber mal warum der VDR bei mir überhaupt solange wartet....
Weil offenbar wartet der plain VDR nach dem automatischen Start lange genug bevor er beschliest wieder runterzufahren weil nix zu tun ist.

Weil bei mir von heute morgen

Edit:

Mar  2 01:20:58 dirk-vdr vdr: [2118] next plugin wakeup at Sat Mar  2 07:57:00 2013

(Wakeup wird 5 Minuten vorher gesetzt, also angegangen ist er um 07:52:00)

Mar  2 07:53:07 dirk-vdr vdr: [2116] VDR version 1.6.0-3 started
Mar  2 08:00:00 dirk-vdr vdr: [2847] xmltv2vdr importer thread started (pid=2116, tid=2847)

Warum wartet der VDR fast 7 Minuten?

Vermutlich nimm er die Wakeupzeit (aus der setup.conf) + SHUTDOWNWAIT (aus der vdr.c). Also hier 07:57 + 5 Minuten, also wäre der Runterfahrversuch 08:02 gewesen.

cu

OleS: Ein Syslog von dem ganzen bräuchte ich schon...

Wie erzeugt das Plugin eigentlich den Aufwachzeitpunkt? Wenn das über NextWakeupTime in der setup.conf landet könnte er es fälschlicherweise als Aufwachen für einen Timer interpretieren - dann müsste man das Timeout hier hochsetzen:
https://github.com/yavdr/yavdr…ddevice-02-script.py#L363

Zitat von seahawk1986

Wie erzeugt das Plugin eigentlich den Aufwachzeitpunkt? Wenn das über NextWakeupTime in der setup.conf landet könnte er es fälschlicherweise als Aufwachen für einen Timer interpretieren - dann müsste man das Timeout hier hochsetzen:
https://github.com/yavdr/yavdr…ddevice-02-script.py#L363

Schau noch mal in Posting 13 unten (ich hatte da noch mal was editiert), ich denke das (Wakeupzeit (aus der setup.conf) + SHUTDOWNWAIT (aus der vdr.c)) wäre der korrekte Zeitpunkt (der immer passt) für den Runterfahrversuch.

Zitat von seahawk1986

Wie erzeugt das Plugin eigentlich den Aufwachzeitpunkt? Wenn das über NextWakeupTime in der setup.conf landet könnte er es fälschlicherweise als Aufwachen für einen Timer interpretieren

Ja, das landet in der setup.conf, der VDR macht ja keinen Unterschied zwischen den verschiedenen Timern. Ihm ist es also wohl egal ob Aufnahmetimer oder Plugin.

cu

OleS: könntest du mal das als /etc/yavdr/templates_custom/etc/init/vdr-frontend.conf/30_softhddevice-02-script.py ausprobieren: https://dl.dropbox.com/u/960809/30_softhddevice-02-script.py
(und mit einem "sudo process-template /etc/init/vdr-frontend.conf" übernehmen)

Hier noch der Diff:

--- /usr/share/yavdr/templates/etc/init/vdr-frontend.conf/30_softhddevice-02-script.py  2013-01-10 22:55:55.000000000 +0100
+++ /etc/yavdr/templates_custom/etc/init/vdr-frontend.conf/30_softhddevice-02-script.py 2013-03-02 11:57:18.239248414 +0100
@@ -70,6 +70,18 @@
     def vdrsetupget(self,option):
         return self.dbussetup.Get(dbus.String(option),dbus_interface=self.interface)


+class dbusTimer():
+    def __init__(self):
+        self.dbusshutdown = bus.get_object("de.tvdr.vdr","/Timers")
+        self.interface = 'de.tvdr.vdr.timer'
+    def wakeup_for_Timer(self):
+        status,tid,rel,startt,stopt,event = self.dbusshutdown.Next(dbus_interface=self.interface)
+        if status == 250:
+            if rel <= (6 * 60):
+                return True
+        else:
+            return False
+
 def get_dbusPlugins():
     '''wrapper for dbus plugin list'''
     dbusplugins = bus.get_object("de.tvdr.vdr","/Plugins")
@@ -348,7 +360,7 @@
     remote = dbusRemote()
     shutdown = dbusShutdown()
     setup = dbusSetup()
-
+    timer = dbusTimer()
     settings = Settings()


     # check if vdr was started because of a timer or an acpi_wakeup event, if not attach frontend
@@ -359,7 +371,7 @@
         subprocess.call(["/usr/bin/feh","--bg-fill",settings.conf['logo_detached']], env=settings.env)


         graphtft_switch()
-        if settings.manualstart == False:
+        if settings.manualstart == False and timer.wakeup_for_Timer():
             settings.timer = gobject.timeout_add(300000, send_shutdown)
         elif settings.acpi_wakeup == True and setup.vdrsetupget("MinUserInactivity")[0] > 0:
             interval, default, answer = setup.vdrsetupget("MinEventTimeout")