[Announce] VDR Plugin epg2vdr 0.0.4 & epgd 0.0.5

Zitat von horchi

schicke einfach ein sighub an den epgd

Ist das nicht eine Holzhammermethode?

kill -s 1 $(pidof epgd)

Zitat von CKone

desweiteren liefert epgdata bspw täglich ~16:30Uhr aus, manchmal auch etwas später - Hast du jetzt nen 12h loop kannst du das leicht verpassen.

aber gerade bei nur einem lokalen VDR ist es doch nicht selten der Fall, dass die Kiste gerade dann nicht läuft - ist ja auch nicht gerade Serientimerzeit
Bei mir ist der VDR meist morgens mal ein paar Stunden an und dann in der Regel tagsüber komplett aus und erst abends wieder in Betrieb. Am Wochenende läuft er auch schon mal mehr und länger durch.

Ich würde den "xx Stunden" Intervall weiterhin bevorzugen, als das fest zu verdrahten. Wo ist jetzt der Nachteil es einfach bei dem einstellbaren Intervall zu belassen? Tut es dem epg-Datenlieferanten weh, wenn die vielen Zugriffe erfolgen, oder was ist der Grund?
Und ändert jetzt epgdata seine Auslieferungszeit auf 18:30 Uhr, muss ja wieder das Plugin angepasst werden.
12h Intervall ist auch schon recht großzügig ... da sollte der User schon was Sinnvolles einstellen

Gruss.
Markus

Zitat von ofenheizer

aber gerade bei nur einem lokalen VDR ist es doch nicht selten der Fall, dass die Kiste gerade dann nicht läuft - ist ja auch nicht gerade Serientimerzeit

grundsätzlich gehen wir von einem Anwendungszenario 24/7 für Daemon und DB aus, dafür wurde das Ding entwickelt: alles andere sind Sonderfälle - bei denen es zweifelsfrei aber auch prima ist wenn es funktioniert

Christian

Ok, so verpasst man sicherlich nix.
Aber wozu es programmiertechnisch und setup-technisch komplizierter machen (weiss nicht ob das der Fall ist, kann nicht programmieren), als es einfach beim einstellbaren Intervall zu lassen?
Plus zusätzlich checkInitial = 0|1 einzuführen.

Wo bedeuten mehrere einstellbare, fest Zeitpunkte denn mehr Flexibilität?

Mit scan beim Start und nochmal nach sagen wir mal 3h ist doch im Prinzip alles abgedeckt (jetzt aus Sicht einer lokal betriebenen DB & epg2vdr).

Ist jetzt so aus meiner Sicht und meinem Verständnis doch völlig ausreichend, wie es gerade gehandelt wird.

Gruss.
Markus

Zitat von CKone

grundsätzlich gehen wir von einem Anwendungszenario 24/7 für Daemon und DB aus, dafür wurde das Ding ebtwickelt: alles andere sind Sonderfälle - bei denen es zweifelsfrei aber auch prima ist wenn es funktioniert

Christian

Das verstehe ich schon Christian.
Aber ich denke mal das auch eine große Anzahl von Usern, die nur einen VDR betreiben, diese Kombi als Ersatz für das ja nun nicht mehr gepflegte Plugin tvm2vdr verwenden und sich jetzt nicht wegen der Software einen Server für das EPG hinstellen

Markus

Initialen Lauf konfigurierbar finde ich auch sinnvoll.

Fester Zeitpunkt bei einem 24/7 System macht auch Sinn. Obwohl auch hier ein Intervall denkbar ist ... gibt ja genug cron-Jobs auf Servern.

Ich kenne die Verteilung nicht, wieviel User es als Server/Client-Lösung betreiben und wieviele es wie das "alte" Plugin nur lokal einsetzen, weil halt nur ein VDR vorhanden ist, nicht. Evtl. sollte man mal eine Umfrage starten :).Denn ich denke in diesem Szenario macht ein Intervall mehr Sinn.

Beides zum implementieren, halte ich auch für unsinnig.

Markus

Moin!

Ein vdr-Plugin kann dem vdr sagen, wann es gerne mal wieder aufwachen möchte. Bei einer Ein-Maschinen-Installation könnte das Plugin also die Update-Zeiten vom Daemon (oder aus der Datenbank) erfragen und beim Herunterfahren dann dafür sorgen, dass der vdr zu gegebener Zeit wieder hochfährt. So macht xmltv2vdr es auch.

Ausschnitt aus "newplugin":

time_t cPlugin${PLUGIN_CLASS}::WakeupTime(void)
{
  // Return custom wakeup time for shutdown script
  return 0;
}

Ob man das nun explizit im Plugin konfigurierbar macht oder das Plugin es von alleine macht bei "Datenbank == localhost" ist Geschmackssache.
Ich bin für explizite Konfiguration.

Lars.

Zitat von ofenheizer

Fester Zeitpunkt bei einem 24/7 System macht auch Sinn. Obwohl auch hier ein Intervall denkbar ist ... gibt ja genug cron-Jobs auf Servern.

ja vllt keine blöde Idee Markus: den loop aus und den Rest aus dem Cron mit

killall -HUP epgd

triggern

Christian

Zitat von mini73

Ein vdr-Plugin kann dem vdr sagen, wann es gerne mal wieder aufwachen möchte. Bei einer Ein-Maschinen-Installation könnte das Plugin also die Update-Zeiten vom Daemon (oder aus der Datenbank) erfragen und beim Herunterfahren dann dafür sorgen, dass der vdr zu gegebener Zeit wieder hochfährt.

danke Lars: das kannte ich nicht.

Hatte letztens eine Abfrage eines Users zu so etwas ähnlichem, glaube es war OleS

Christian

Zitat von CKone

ja vllt keine blöde Idee Markus: den loop aus und den Rest aus dem Cron mit

Code

killall -HUP epgd

triggern

ich muss mich selber noch mal aufgreifen: ich find das sogar besser weil ich da viel flexibler bin: kann ich das 16:30 am Wochenende auslassen wenn die Vögel die Redaktion geschlossen haben

sonen richtigen scheduler mit all seinen Möglichkeiten hätten wir ja eh nicht eingebaut: also ja, warum nicht?

Kombiniert mit dem Vorschlag von Lars natürlich für das tägliche Update der Betreiber von lokalen Daemon/DB...

Christian

Ich denke die initiale Abschaltung ist wichtig, den im ungünstigsten
Fall kann der vdr 5 mal am Tag aufwachen ( Serientimer) und jedesmal
wird ein unötiges update gemacht.

Wenn man den Zeitpunkt des letzte update in
db schreibt, kann man es mit dem interval Wert in der conf vergleichen
und wenn abgelaufen ein update starten. ( wäre aber auch über ein Script
und cron möglich, ist halt nicht so elegant)

Feste Zeiten sind
mir jetzt nicht wichtig, denn wenn man einen forecast von 16Tagen hat
kommt es auf 10 oder mehr Stunden eh nicht darauf an wann die neuen
Daten verfügbar sind, und ob die kurzfristige Sondersendungen überhaupt
verwenden glaub ich nicht

rookie1

Zitat von rookie1

Feste zeiten sind
mir jetzt nicht wichtig, denn wenn man einen forecast von 16Tagen hat
kommt es auf 10 oder mehr Stunden eh nicht darauf an wann die neuen
Daten verfügbar sind, und ob die kurzfristige Sondersendungen überhaupt
verwenden glaub ich nicht

es geht nicht um Quantität sondern um Qualität, und deshalb ist es einer der wichtigsten Aufgaben des Plugins abends zur Primetime für die konfigurierten DaysToUpdate das absolut aktuellste File drin zu haben. - und nochmal: wenn ich den loop auf 12h oder mehr steht dann krieg ich das leicht nicht mit. Das Plugin ist inteligent genug die Files auf dem Server des Providers zu checken und bereits bekanntes gar nicht erst runterzuladen.

Christian

Zitat von CKone

es geht nicht um Quantität sondern um Qualität, und deshalb ist es einer der wichtigsten Aufgaben des Plugins abends zur Primetime für die konfigurierten DaysToUpdate das absolut aktuellste File drin zu haben. - und nochmal: wenn ich den loop auf 12h oder mehr steht dann krieg ich das leicht nicht mit. Das Plugin ist inteligent genug die Files auf dem Server des Providers zu checken und bereits bekanntes gar nicht erst runterzuladen.

Christian

He, nicht falsch verstehen es spricht für mich nichts dagegen dies zu implemntieren, hängt vom Entwickler ab,

Nur glaube ich nicht das sich plötzlich der Inhalt eines Film oder Serie ändern soll, sondern kann es sich max. Programmänderungen handeln und da ist halt entscheident wie schnell der Epg Lieferant ist

rookie1

Zitat von CKone

Hatte letztens eine Abfrage eines Users zu so etwas ähnlichem, glaube es war OleS

Jupp, das war ich. Wenn die Updatezeit des epgd und die Aufwachzeit des VDR vom Plugin getriggert werden würde,
könnte ich mir den Umweg über vdr-addon-acpiwakeup.conf zum Aufwachen und crontab zum Schlafengehen sparen.
Funktioniert zwar, ist aber nicht besonders schön gelöst (sollte ich zum Zeitpunkt des crontab-Eintrages mal fernsehen,
muss ich wieder hektisch zur FB greifen, damit die Kiste nicht runterfährt. Zugegeben: kommt selten vor, denn das
Poweroff kommt gegen 3:30 Uhr... Dennoch wäre ich von einer anderen Lösung mehr als begeistert.

Cheers,
Ole