EPG Aktualisierung

[tvfreak2]

Dem Wunsch kann ich mich nur vollumfänglich anschließen.

[MCMUPPET]

Bitte die Suchfunktion des Forums zu diesem Thema benutzen. Mit einer Laufzeitanpassung würde man User mit Beginnerstatus einen nicht manuell programmierten Zeitraum zugänglich machen. Außerdem würden alle vor der Änderungen getätigten Programmierungen ungültig sein. Die User müssten erneut programmieren. Aber wir wiederholen uns zu diesem Thema bereits. Man programmiert bei OTR einen Zeitraum (laut EPG Zeiten) und nicht nach Titel der Aufnahme.

MfG
MCMUPPET

[TikTok]

Sicher wäre eine automatische Anpassung der Idealfall und sehr wünschenswert. Ich persönlich wäre aber schon zufriedener, wenn das EPG nicht ähnlich veraltet wäre wie meine Fernsehzeitung, schließlich hat die sicher einen Vorlauf von mindestens 2 Wochen. Im digitalen Bereich sollte eine kurzfristigere Aktualisierung aber leicht machbar sein, zumal ja die Sender mit dem TV-Programm den aktuelleren Videotext gleich mitliefern. Finde es schon ärgerlich, wenn man bei der Programmierung schon weiß, daß die Sendung verschoben wurde und man daran nichts korrigieren kann.

[worfroz]

das EPG zeitnah zu aktualisieren und die programmierten Sendungen (sofern sie sich verschieben) automatisch zu aktualisieren.

Das ist auch rechtlic (bezogen auf die Dekodiererlaubnis) nicht ganz so einfach, wie es technisch scheinen mag. Beispiel: Ein Beginner programmiert heute um kurz nach 19 Uhr eine Sendung gem. EPG von 20:15 bis 21:00 Uhr in der ARD, da soll heute #Beckmann laufen. Nun soll (nicht wirklich, nur hier im Beispiel) aus aktuellem Anlaß eine Sondersendung laufen, die von 20:15-20:30 Uhr läuft. Problem: Was will der User tatsächlich? Programmiert er den EPG-Zeitraum, weil er die Sondersendung aufnehmen möchte? Oder war sein Ziel die genannte ursprüngliche Sendung? Paßt OTR nun das EPG an und verschiebt die Beckmann-Aufnahme entsprechend den neuen Sendezeiten, dann hat der User Glück, wenn der diese Sendung haben wollte - und Pech, weil ihm dann die Dekodiererlaubnis für die evtl. gewünschte Sondersendung fehlt. Da hilft dann auch ein Ausrufezeichen im EPG nicht. Je kurzfristiger die EPG-Anpassung ist, umso größer werden dann die Probleme - oder würdest Du unmittelbar vor den Sendungen noch mal schnell ins EPG schauen wollen, ob sich da vielleicht doch noch etwas geändert haben könnte?

Nun mag man argumentieren, daß das ja nur Beginner betrifft und die Premium-User ja ihre Get-It-All-Wishlist (bzw. den Recorder) haben. Das stimmt nur zum Teil, denn die einzelnen Programmierungen sind der einzige Indikator für Sonderformate wie derzeit HQ. Die Änderung des EPG könnte sich dann auf diese Programmierungen auswirken.

[AndyK70]

Beispiel: Ein Beginner programmiert heute um kurz nach 19 Uhr eine Sendung gem. EPG von 20:15 bis 21:00 Uhr in der ARD, da soll heute #Beckmann laufen. Nun soll (nicht wirklich, nur hier im Beispiel) aus aktuellem Anlaß eine Sondersendung laufen, die von 20:15-20:30 Uhr läuft. Problem: Was will der User tatsächlich? Programmiert er den EPG-Zeitraum, weil er die Sondersendung aufnehmen möchte? Oder war sein Ziel die genannte ursprüngliche Sendung?

Das würde ich genauso entscheiden lassen, wie bei den Pooling-Sendern oder die Entscheidung, ob nun HD/HQ Formate codiert werden.
Wenn bis zum Vortag 06:00Uhr der Ausstrahlung die Sendung programmiert ist, dann wird die Programmierung angepasst.
Ist die Programmierung neuer, dann wird sie nicht angepasst, bei einer EPG Aktualisierung aber dennoch mit einem Hinweis versehen.

Wenn diese Regelung vorher bekannt gemacht werden würde, dann kann man sich darauf einstellen und Sonderformate aus gegebenem Anlass sind ja meistens nicht schon länger als 24h bekannt, oder?

[MCMUPPET]

Da haben wir User (auch Beginner) also auch Zugriff auf nicht programmierte Zeiträume... Nö, das sehe ich anders, denn der Programmierauftrag beinhaltet den Overlap. Wer den Overlap nicht nicht nutzen möchte, programmiert nicht. Der User beauftragt somit Aufnahme des Zeitraums + Overlap.

MfG
MCMUPPET

[AndyK70]

Nö, das sehe ich anders, denn der Programmierauftrag beinhaltet den Overlap. Wer den Overlap nicht nicht nutzen möchte, programmiert nicht. Der User beauftragt somit Aufnahme des Zeitraums + Overlap.

Dann nehme ich genau das Argument pro Feature Programmieranpassung: Wenn OTR eine Anpassung der Programmierung als Service anbietet ist das auch Teil der Programmierung. Wer das nicht möchte, der programmiert halt nicht.

Interessant finde ich vor allem, dass immer wieder gegen neue Features argumentiert wird, anstatt über Möglichkeiten zu diskutieren, wie es realisiert werden könnte.

[MCMUPPET]

Der User muss den Zeitraum programmieren und nicht OTR.

MfG
MCMUPPET