Vor- und Nachlauf bei Aufnahmen

Hmm, die epgsearch-Suchtimer können das. Für so kurze Nachlaufzeiten wäre vielleicht markad-ng mit "vps light" eine Möglichkeit.

Quote from CyberHogo

Die Timer-Ende- Berechnung erhält in folgenden Fällen eine Endzeit, die von der im Setup vorgegebenen Zeit (bei mir +30 Min.) abweicht:

Wenn die auf den Timer nachfolgene Sendung früher endet als der Nachlauf, wird die Endezeit auf das Ende der nachfolgenden Sendung minus einer Minute gesetzt. Also in meinem Fall immer, wenn die nachfolgende Sendung kürzer als 30 Min. ist.

Kann das jemand bei sich nachvollziehen? Ich finde kein Szenario, in dem diese Berechnung sinnvoll ist, aber wer weiß.

Wo kann das herkommen?

Display More

Ich denke, das hat Klaus so implementiert, um dem Timer eindeutig ein Event zuordnen zu können.

kls , stimmt das so?

Quote from MarkusE

Ich denke, das hat Klaus so implementiert, um dem Timer eindeutig ein Event zuordnen zu können.

kls , stimmt das so?

Ja, das ist so.

Quote from wmautner

Für so kurze Nachlaufzeiten wäre vielleicht markad-ng mit "vps light" eine Möglichkeit.

Nein, weil markad niemals Timer verändert.

Quote from kls

Ja, das ist so.

Ok, das macht ja auch Sinn. Freue mich, die Begründung für das Verhalten gefunden zu haben. Evtl. könnte man eine solche Manipulation des Timers noch irgendwo vermerken? Syslog? Info der Aufnahme?

Mit der Erkenntnis, kann/muss ich dann leben.

Man kann das übrigens IIRC auch abstellen. Es gibt hier im Forum irgendwo einen Patch dafür.

Quote from CyberHogo

Mit der Erkenntnis, kann/muss ich dann leben.

Nicht unbedingt.

Man könnte im timer auch Event id, Event Startzeit und Event Stopzeit ablegen. Und dann damit das korrekte Event finden.

Das würde mir in markad auch helfen, den Event zum Timer zu finden. Stand heute mache ich das auch über Start/Ende.

Aber muss denn ein Timer einen 1:1 Bezug zu einem Event haben ? Ich habe es kurz getestet: Ich kann einen Timer von 00:00 Uhr bis 08:00 Uhr anlegen. Da liegen viele Events drin.

Auf Event-IDs ist kein Verlass. Es gibt Sender, die ändern die Event-IDs immer wieder.

Quote from kfb77

Aber muss denn ein Timer einen 1:1 Bezug zu einem Event haben ?

Siehe CalcMargins():

void cTimer::CalcMargins(int &MarginStart, int &MarginStop, const cEvent *Event)
{
  MarginStart = Setup.MarginStart * 60;
  MarginStop  = Setup.MarginStop * 60;
  // 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));
}

Würde ein Timer mit mehr als einem Event zu 100% überlappen, wäre nicht mehr klar, welchem Event er im Falle einer Verschiebung der Start- bzw. Stoppzeit folgen soll. Das gilt nur für Pattern-Timer ohne VPS. Mit VPS kommt es eh nur auf die VPS-Zeit an.

Quote from kls

Auf Event-IDs ist kein Verlass. Es gibt Sender, die ändern die Event-IDs immer wieder.

Stimmt. Deshalb war mein Vorschlag ja auch, Event id, Event Startzeit und Event Stoppzeit abzulegen.

Dann kann das korrekte Event über Event Startzeit und Event Stoppzeit gefunden werden, falls sich die Event id ändert.

Das ist besser, als das über die Timer Startzeit und Timer Stoppzeit zu machen.

Quote from MarkusE

Stimmt. Deshalb war mein Vorschlag ja auch, Event id, Event Startzeit und Event Stoppzeit abzulegen.

Dann kann das korrekte Event über Event Startzeit und Event Stoppzeit gefunden werden, falls sich die Event id ändert.

Das ist besser, als das über die Timer Startzeit und Timer Stoppzeit zu machen.

Und was ist, wenn sich Start- oder Stopzeit ändern und dann ggf. noch die EventId.

Wie man es dreht und wendet, wenn alles dynamisch ist, gibt es halt nur schlechte Lösungen. Da muss man dann die am wenigsten Schlechte wählen. Das scheint mir die Aktuelle zu sein.

Dass es Events von nur wenigen Minuten gibt, kommt wohl recht selten vor.

RTL macht da mit dem Wetter halt was Besonderes. Verstehe ich aber auch, weil die das dann im Straming separat anbieten wollen.

Irgendwie finde ich es halt unschön, wenn ein Anwender VDR mitteilt, dass der Timer um 12.15 beendet sein soll. Und VDR dann entscheidet, den Timer doch lieber schon um 12:10 zu beenden (warum auch immer).

Von daher wäre mein Vorschlag besser. Andererseits verstehe ich auch, wenn Klaus keine weiteren Felder in die Timer mit aufnehmen möchte. Und in der Praxis ist das Ändern der Timer-Stoppzeit vermutlich kein reales Problem.

> Und was ist, wenn sich Start- oder Stoppzeit ändern und dann ggf. noch die EventId.

Ziel meines Vorschlages war es nicht, eine garantiert immer funktionierende Methode zur Zuordnung des Events zu finden. Ziel war es, eine Methode zu finden, bei der es nicht notwendig ist, vom Anwender in den Timer eingegebene Zeiten zu ändern.

Quote from MarkusE

Irgendwie finde ich es halt unschön, wenn ein Anwender VDR mitteilt, dass der Timer um 12.15 beendet sein soll. Und VDR dann entscheidet, den Timer doch lieber schon um 12:10 zu beenden (warum auch immer).

Das sollte aber doch nur für Timer geschehen, die von Pattern Timern abstammen ("spawned").

Siehe auch:

        else if (HasFlags(tfSpawned)) {
           if (!Margin && !Directly) { // this is an actual check
              // The spawned timer's start-/stopTimes are adjusted to the event's times in AdjustSpawnedTimer().
              // However, in order to make sure the timer is set to the correct event, the margins at begin
              // end end are limited by the durations of the events before and after this timer's event.
              // The recording, though, shall always use the full start/stop margins, hence this calculation:
              return event->StartTime() - Setup.MarginStart * 60 <= t && t < event->EndTime() + Setup.MarginStop * 60;
              }
           }

Gibt es ein konkretes, nachvollziehbares Beispiel für das Problem?

Quote

Gibt es ein konkretes, nachvollziehbares Beispiel für das Problem?

Bin mir nicht sicher, ob mein "Problem" gemeint ist.

Ich nehme täglich RTL Aktuell um 18.45 Uhr auf (Suchtimer Epgd). Im Anschluss kommt für eine oder zwei Minuten RTL Wetter mit dem Ergebnis, dass die Nachrichten oft nicht mehr ganz drauf sind.

Das habe ich erst nach dem Wechsel auf jammy. Zuvor hat es 20 Jahre funktioniert.

PS: im Suchtimer suche ich "RTL Aktuell" mit exakter Übereinstimmung. Wäre ja nicht pattern, oder?

Quote from CyberHogo

PS: im Suchtimer suche ich "RTL Aktuell" mit exakter Übereinstimmung. Wäre ja nicht pattern, oder?

Was Epgd mit Suchtimern macht, weiß ich nicht.

Ich nehme halt einfach mit einem täglichen Timer von 18:45 bis 19:15 auf und fertig.

In "timers.c":

void cTimer::CalcMargins(int &MarginStart, int &MarginStop, const cEvent *Event)
{
  MarginStart = Setup.MarginStart * 60;
  MarginStop  = Setup.MarginStop * 60;
  // 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));
}

Und das wird nicht nur bei "spawned" Timern verwendet, sondern eigentlich immer.

Lösungsvorschlag: CalcMargins ändern:

void cTimer::CalcMargins(int &MarginStart, int &MarginStop, const cEvent *Event)
{
  MarginStart = Setup.MarginStart * 60;
  MarginStop  = Setup.MarginStop * 60;
}

Und dann, wenn das Event zu einem Timer nicht gefunden wird, weil der Timer 2 oder mehr Events umfasst: Die Timer Zeiten entsprechend um Setup.MarginStart und Setup.MarginStop verkürzen, and danach das Event noch mal suchen.

Vorteil:

• Kein zusätzliches Feld im Timer notwendig. Drei solche zusätzlichen Felder wären eigentlich die beste Lösung.

Nachteil:

• Kann zu Fehlern führen, wenn Setup.MarginStart und Setup.MarginStop nach dem Anlegen des Timers verändert werden. Sehe ich aber eher als theoretisches Problem.
• Kann zu Fehlern führen, wenn der Timer nicht zu einem Event angelegt wird, sondern komplett manuell. Ist aber wohl auch eher ein theoretisches Problem.

Quote from MarkusE

Und das wird nicht nur bei "spawned" Timern verwendet, sondern eigentlich immer.

Stimmt, hatte ich nicht mehr auf dem Schirm.

Für Spawned-Timer läuft die Aufnahme läuft uf jeden Fall mit den vollen Start-/Stop-Margins.

Siehe cTimer::Matches():

        else if (HasFlags(tfSpawned)) {
           if (!Margin && !Directly) { // this is an actual check
              // The spawned timer's start-/stopTimes are adjusted to the event's times in AdjustSpawnedTimer().
              // However, in order to make sure the timer is set to the correct event, the margins at begin
              // end end are limited by the durations of the events before and after this timer's event.
              // The recording, though, shall always use the full start/stop margins, hence this calculation:
              return event->StartTime() - Setup.MarginStart * 60 <= t && t < event->EndTime() + Setup.MarginStop * 60;
              }
           }

Eventuell würde es ja helfen, die Abfrage auf tfSpawned einfach wegzulassen, so dass dies für alle (nicht VPS-)Timer gilt?

Timer nimmt nur dann von Timer Start bis Timer Stopp auf, wenn dem Timer kein Event zugeordnet werden kann.

Falls dem Timer ein Event zugeordnet werden kann, dann wird Timer Start und Timer Stopp ignoriert, und Timer nimmt auf von (Event Start - Margin) bis (Event Stopp + Margin). Außer VPS timer.

Spannendes Feature, dann würde VDR bei Aufzeichnungen auf Verschiebungen der Events reagieren. So eine art VPS light, auch wenn der Sender VPS nicht unterstützt. Man sollte dann halt möglichst sicherstellen, dass man auch das richtige Event erwischt hat. Ev. nochmal den Event Title mit dem Timer Namen vergleichen?

Ich denke, dass epgsearch etwas ähnliches kann, nennt sich da Timer überwachen.

Was passiert denn, wenn ich mit einem Timer absichtlich 3 Events aufnehmen möchte, also den Timer entsprechend lang setze?

Mache ich bei UK Sendern, die einen Film in 2 Teile teilen, und dazwischen 5 min Nachrichten senden. Und dann im EPG 3 Events da draus machen.

Ich clicke dann auf das erste Event, um den Timer daraus zu erzeugen. Und verschiebe die Stopp Zeit manuell so weit nach hinten, dass alle 3 Events aufgenommen werden.

Quote from MarkusE

Was passiert denn, wenn ich mit einem Timer absichtlich 3 Events aufnehmen möchte, also den Timer entsprechend lang setze?

Guter Einwand. Also erstmal alles so lassen, wie es ist.

Ich möchte mal ein konkretes (nachvollziehbares) Beispiel sehen, wo sich ein Problem ergibt.