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

  • Seit Version 2.5.2 werden Timer anders angelegt als früher (hier).

    Wenn die folgende Sendung kurz ist, ist der Nachlauf entsprechend kurz.

    Das ist mir zu wenig Sicherheit für später anfangende Sendungen.

    Was kann ich tun, um das alte Verhalten wieder zu bekommen?

    Jeden Timer von Hand editieren wäre nicht das, was ich möchte.

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

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

    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

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • 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?

  • 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

    VDR 2.6.1: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 36 Kernel 6.0 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ein Vorschlag für eine weniger radikale Lösung wäre, das Prinzip von #2 konfigurierbar zu machen.

    Sowas wie "Angrenzende Events begrenzen Vor/Nachlauf" An/Aus.


    Oder vielleicht noch besser wäre es, beim Umwandeln von regulärem Timer zu Pattern-Timer und zurück die Start/Stop-Zeiten entsprechend anzupassen.

    Also wenn man einen regulären Timer mit Gelb umwandelt, wird Vor/Nachlauf gemäß dem Event begrenzt und umgekehrt.

  • 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.

  • 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.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • 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.