VDR 2.6.1 Sicherheits-Nachlauf für verspätete Sendung zu klein

Das wurde notwendig um sicherzustellen, dass der Timer immer dem richtigen Event zugeordnet wird.

Du kannst das vorherige Verhalten wiederbekommen, indem du folgendes machst:

void cTimer::CalcMargins(int &MarginStart, int &MarginStop, const cEvent *Event)
{
  MarginStart = Setup.MarginStart * 60;
  MarginStop  = Setup.MarginStop * 60;
  return; // <------------------------------------- hier dieses Statement einfügen
  // To make sure the timer gets assigned to the correct event, we must
  // make sure that this is the only event that overlaps 100%:
  if (const cEvent *e = dynamic_cast<const cEvent *>(Event->Prev()))
     MarginStart = max(0, min(MarginStart, e->Duration() - 60));
  if (const cEvent *e = dynamic_cast<const cEvent *>(Event->Next()))
     MarginStop = max(0, min(MarginStop, e->Duration() - 60));
}

Allerdings kann es dann sein, dass Pattern-Timer nicht mehr richtig funktionieren.

Hi Klaus,

Irgendwie überzeugt mich Deine Lösung jetzt nicht.

Es muss doch möglich sein, beides zu erreichen:

• Der Timer wird immer dem richtigen Event zugeordnet
• Ich kann den Nachlauf so lange einstellen, wie ich möchte. Unabhängig von der Länge der nachfolgenden Sendung

Ev. ein weiteres Timer Attribut, das die Länge des Nachlaufs festhält? So dass das Timer -Ende ohne Nachlauf ermittelt werden kann?

~ Markus

Sehe ich auch so. Ich hatte das auch schon das ich von was kurzem mehrere Folgen hintereinander aufnehmen wollte und das war dann mit VDR Mitteln gar nicht so einfach zu programmieren weil eine Folge einen Timer erstellt hat der mehrere Folgen "überstrichen" hat. Warum nicht generell Timer fest auf's Event und konfigurierten Vor- und Nachlauf dann da immer mit drauf?

Die Zuordnung von Timern zu Events ist nur über die Zeit möglich. Zum einen handhaben die Sender die Event-IDs nicht eindeutig (siehe dazu meine gesammelten Erkenntnisse in eit.c), zum anderen könnte man sonst keinen Timer programmieren, für den es (noch) keinen Event gibt.

Die Vor-/Nachlaufzeit wird beim Anlegen eines neuen (nicht-VPS-)Timers über den EPG sofort zu den Start-/Stopzeiten des Events dazugeschlagen. Das hat den Vorteil, dass man dem Timer immer genau ansieht, von wann bis wann er läuft. Man könnte natürlich auch den Timer mit genau den Zeiten des Events anlegen und die Vor-/Nachlaufzeiten erst in cTimer::Matches(time_t t, ...) berücksichtigen. Damit würde das ganze CalcMargins()-Gedöns wegfallen und es könnte an einigen Stellen sogar einfacher werden. Allerdings ist dabei zu bedenken:

- Eine Änderung der Vor-/Nachlaufzeiten im Setup würde sofort auf alle existierenden Timer wirken (was man auch als Vorteil sehen kann).

- In der Timer-Liste und in z.B. der LCARS-Skin würden nicht mehr die tatsächlichen Start-/Stopzeiten angezeigt, sondern die des Events (was aber bei VPS-Timern auch schon so ist).

- Es wäre nicht mehr ohne weiteres möglich, einen Timer von Hand so anzulegen, dass er zu einer genau gewünschten Zeit startet/stoppt, da man immer die Vor-Nachlaufzeit ins Kalkül ziehen müsste.

Meinungen dazu?

Würde etwas dagegen sprechen ein "Boolean" mit an den Timer zu hängen um zu steuern ob Vor- und Nachlauf gewünscht ist? Bei manuellem Timer dann per Default auf "False" und bei Programmierung aus dem EPG dann "True".

M-Reimer: Ungern Den dritten Punkt hatte ich eher der Vollständigkeit halber aufgeführt, da der Fall ja doch eher selten sein dürfte.

Wobei man das nachträglich immer noch realisieren könnte, sollte es notwendig werden.

Bei diesbezüglichen Änderungen sollte auf jeden Fall das Verhalten der vorhandenen Plugins (wie epgsearch, o.ä.) berücksichtigt werden.

Nicht das es dann wieder zu Inkompatibilitäten , wie bei dieser Änderung "Deleting expired timers is now triggered immediately after the timers are modified" kommt, die sich leider bisher nicht zu 100% fixen ließ.

Grüße

kamel5

kamel5: Natürlich käme sowas erstmal in einer Version 2.7.x, und nicht in der Stable 2.6.

Ich wollte erstmal nur wissen, ob so eine Änderung gewünscht ist, denn ich selber habe mit dem jetzigen Verhalten kein Problem.

Würde es nicht ausreichen die ohnehin konfigurierten Vor- und Nachlaufzeiten beim Zuordnen eines Timers zum Event einfach "rückwärts" anzuwenden? Also Aufaddierten Vor- und Nachlauf abziehen und dann gegen das Event checken. Und es würde reichen das zu tun wenn ein Timer auf zwei Events zutreffen würde.

Zitat von kls

Allerdings kann es dann sein, dass Pattern-Timer nicht mehr richtig funktionieren.

Nur mal unqualifiziert gedacht: und wenn vdr intern mit dem Event, bereinigt um die einstellbare Vor- und Nachlaufzeit rechnen würde?

Christian

Bei genauerem Hinsehen macht der Vorschlag von M-Reimer durchaus Sinn, ja ist sogar notwendig, damit bestehende Timer nach einem Wechsel auf die dann neue Version korrekt weiterlaufen. Wenn das Flag gesetzt ist werden die Vor-/Nachlaufzeiten in Matches() hinzugefügt, ansonsten nicht. Und Flag-Bits haben wir ja noch genügend ;-).

Also etwa so:

Wir speichern in einem Flag, ob der Timer aus einem EPG Event angelegt wurde.

Falls nein, wird nicht versucht, diesem Timer ein Event zuzuordnen.

Falls ja, wird zur Ermittlung des korrekten Events zunächst die Vor- und Nachlaufzeit abgezogen, und danach werden die Zeiten mit dem EPG Event verglichen.

Ansonsten müsste nichts geändert werden, und das Verhalten aus Sicht des Benutzers ändert sich auch nicht.

Nicht ganz. Das Flag gibt an, ob bei dem (nicht-VPS-)Timer die Vor-/Nachlaufzeit zu den im Timer festgelegten Start-/Stopzeiten draufgeschlagen werden sollen. Wird der Timer aus einem Event heraus angelegt, werden seine Zeiten auf die des Events gesetzt und das Flag auf '1' gesetzt. Ansonsten ist das Flag '0' und alles bleibt beim Alten. Eine Event-Zuordnung findet unabhängig davon immer statt.