Jump to content

EPG: Dritte Sendung bei ZDF-Sender fehlt


Basic.Master

Recommended Posts

Seit einiger Zeit (aktueller DMS 2.1.4.0) habe ich ein Problem, was ich noch nicht hundertprozentig reproduzieren kann, aber was ich schon mehrmals gesehen habe:

Ich habe eine Sendung auf einem der ZDF-Sender (ZDF HD oder 3sat HD z.B.) einprogrammiert im DMS, die irgendwann später kommt. Vorher habe ich eine oder mehrere Sendungen auf ARD-Sendern.

 

Irgendwann während den Aufnahmen auf den ARD-Sendern ist es dann so, dass in der Timer-Liste bei der ZDF-Sendung der Eintrag auf einmal kein Link mehr ist = kein EPG-Eintrag (mehr) vorhanden. Wenn ich via Sender-EPG bei dem Sender nachgucke, ist diese Sendung tatsächlich nicht mehr im EPG gelistet und dort eine Lücke. In dem Fall ist es immer die Sendung, die beim Sender-EPG an dritter Position käme; die anderen Sendungen vorher/nachher sind da. Die besagte Sendung ist natürlich jetzt auch keine, die ausfällt oder so.

 

Meine Vermutung ist, dass es irgendwie damit zusammenhängt, dass die ARD-Sender auch Present/Following-EPG für die ZDF-Sender ausstrahlen und da beim EPG-Update irgendwo was runterfällt...aber ich konnte es bisher nicht genau einkreisen. Es ist halt nur heute wieder aufgetreten gerade, mit "Der lange Abschied von der Kohle" um 22:25 auf 3sat HD...

Link to comment

Ich konnte es gerade reproduzieren. Nachdem ich im Webinterface die Wiedergabe des Ersten HD eingeschaltet hatte, fehlte bei 3sat eine Sendung (Kulturzeit ab 09:07):

 

Zwischenablage01.png

 

Nach dem Einschalten von 3sat erschien sie wieder:

 

Zwischenablage02.png

 

Der ursprüngliche EPG von 3sat war schon älter. Man sieht auf dem zweiten Bild die Aktualisierung. Bei "Hart aber fair" sind Informationen hinzugekommen, und die Anfangszeiten haben sich etwas verschoben. Danach habe ich erneut auf das Erste HD umgeschaltet, wonach der EPG jedoch stabil und "Kulturzeit" vorhanden blieb.

 

Die Ursache für das Verschwinden von "Kulturzeit" war wahrscheinlich eine Zeitverschiebung. Der DMS markiert EPG-Einträge nach etwa einer halben Stunde als "alt". Ebenso alle Einträge, die er beim Start aus der epg.dat liest, und auch seine gesamte Sammlung nach dem Aufwachen des PC aus dem Energiesparmodus oder Ruhezustand. Neu eintreffende Einträge werfen als alt markierte Einträge raus, wenn sie sie um mehr als eine Minute überlappen. Genau das ist offenbar im obigen Fall passiert.

 

Das ersatzlose Verschwinden von "Kulturzeit" resultiert daraus, dass der Transponder des Erste HD nicht den vollständigen 3sat-EPG überträgt, sondern sich auf die Present/Following-Einträge beschränkt. Es gibt also keinen aktualisierten Ersatz für den alten "verdrängten" Kulturzeit-Eintrag, bis diese Sendung selbst zu "Present" oder "Following" wird. Und dann verschwindet womöglich zeitweilig eine andere Sendung mit geänderter Anfangszeit.

 

Der Verdrängungsmechanismus resultiert aus einer Änderung im DMS 2.1.2:

 

On 8/19/2018 at 12:20 PM, hackbart said:

Geändert/Fix: EPG: Neue Strategie für die Behandlung eintreffender EPG-Daten im Verhältnis zu bereits vorhandenen Daten, die das Aktualisierungsverhalten des EPG verbessert (siehe hier).

 

Über den "hier" Link gibt es weitere Erläuterungen zu der Vorgehensweise. Sie verhindert andere (größere) Probleme mit dem EPG, die früher öfters auftraten, insbesondere ausbleibende Aktualisierungen oder das Verschwinden größerer EPG-Teile bei Anbietern, die anlässlich einer EPG-Aktualisierung sämtliche Event IDs austauschen, oder noch schlimmer, ihnen andere Sendungen als zuvor zuordnen.

 

Wie sich das hier besprochene Problem lösen lässt, ohne die früheren Probleme wieder hervorzurufen, weiß ich zur Zeit nicht... Vorschläge?

 

Link to comment

Ah, so kleine Updates bei der Zeit habe ich bei 3sat tatsächlich in der letzten Zeit beobachten können. Das erklärt dann auch, warum das Problem bis jetzt nicht so oft und auch nur bei ZDF/3sat aufgetreten ist.

 

Theoretisch könnte man sagen:
Wenn für einen Sender in einem Fremdmux in der EIT nur present/following, aber kein schedule ausgestrahlt wird UND der Sender bereits EPG-Einträge hat (in dem Sinne, dass mindestens zwei EPG-Einträge existieren, die zeitlich present/following entsprächen), dann wird der Sender fürs EPG-Update ignoriert. "Sender bereits EPG-Einträge" würde sicherstellen, dass man wenigstens irgendwas bekommt, falls die gespeicherten Einträge des Sender-EPGs mittlerweile komplett überholt sind.

 

Oder man geht diesen Grenzfall mit dem dritten Eintrag an und behält ihn, wenn dieser Überschneidungsfall auftritt, sowie eben p/f im Fremdmux ohne schedule vorliegt.

 

Die erste Lösung würde das Problem wohl indirekt beheben; halt mit dem Nachteil, dass vorhandene EPG-Daten nicht genutzt werden....eine schwierige Frage.

Link to comment
10 hours ago, Basic.Master said:

Wenn für einen Sender in einem Fremdmux in der EIT nur present/following, aber kein schedule ausgestrahlt wird...

 

Informationen darüber, welche Daten der Transponder für einen bestimmten Sender liefert bzw. nicht liefert, liegen an der betreffenden Stelle nicht vor. Stelle dir das ganze datenbankmäßig vor. Es gibt dort vorhandenen EPG-Einträge und einen neu eintreffenden Datensatz, jeweils mit Titel/Beschreibung, Anfangszeit, Dauer, Network/Transportstream/Service/Event ID, Running Status, eventuell noch PDC und Content. Dem Running Status kann man entnehmen, ob es sich um einen Present/Following oder Schedule-Eintrag handelt, aber mehr ist da nicht drin. Und dann müssen die vorhandenen Daten und der neue Datensatz irgendwie in ein Verhältnis zueinander gesetzt werden.

 

Das grundlegende Problem ist dabei, dass es in der Praxis keinen sicheren Anker gibt, anhand dessen man eine Sendung wiedererkennen kann. Eigentlich sollte es die Event ID sein, aber die variieren diverse Anbieter im Verlauf der Zeit nach eigenem Gutdünken. Entweder werden die IDs bei jedem EPG-Update komplett ausgetauscht, oder bei jeder Zeitverschiebung eine neue ID vergeben, usw.

 

Selbst die PDC der ÖR ist mitunter von zweifelhaftem Wert, z.B. bei zweigeteilten Sendungen (zwei Fußball-Halbzeiten mit Nachrichten dazwischen), bei denen die einzelnen Stücke die gleiche PDC, aber verschiedene Event IDs haben... da habe ich schon diverse Varianten gesehen, selbst bei ein und dem selben Sender mal diese und mal jene. Durch PDC und Running Status gesteuerte Aufnahmen enden deshalb öfters mit Anwender-Frust, siehe hier, und ich habe es inzwischen aufgegeben, dem hinterherzulaufen. Wenn man sich detailliert mit dem EPG und der Aufnahmesteuerung beschäftigt (was ich eine ganze Weile gemacht habe), stellt man fest, dass auch die deutschen ÖR das System nicht so im Griff haben, dass es eine ausreichende Zuverlässigkeit gewährleistet.

 

Link to comment

Ich kannte das ursprüngliche Problem, wo z.B. nach Einschieben einer Sondersendung durch einen Sender dann in der Timeline alte und neue Sendungen überlappend angezeigt wurden. War nicht schön ...

 

Bisher ging ich davon aus daß der Fix darin bestand, beim Eintreffen von EPG-Einträgen vorhandene im gleichen Zeitfenster zu löschen und mit den neuen zu ersetzen. Da sollte ja nichts passieren wenn die Now/Next-Einträge zeitgleich mit schon vorhandenen sind. Dann würden genau die beiden durch die ggf. beiden "neuen" gleichen ersetzt, alles drumherum aber in Ruhe gelassen. Nur wenn sich laut Now/Next eine Sendung plötzlich verlängert würde die dann überlappte dritte Sendung gelöscht.

 

Ist das Verhalten so oder anders? Oder ist die Prüfung auf Überlappung vielleicht zu streng, so daß deswegen die dritte Sendung gelöscht wird obwohl nicht nötig. Hatte bisher keine Zeit es selber nachzustellen aber wenn genau die Sendung nach Now/Next gelöscht wird, die nachfolgenden aber nicht wäre das ein Verdacht. Wenn die rechnerische Überschneidung sehr klein ist könnte man da vielleicht eine Toleranz einführen die ganz minimale Überlappungen erlaubt und so die dritte Sendung nicht löscht.

Link to comment
10 hours ago, HaraldL said:

Ist das Verhalten so oder anders?

 

 Es ist so.

 

10 hours ago, HaraldL said:

Oder ist die Prüfung auf Überlappung vielleicht zu streng, so daß deswegen die dritte Sendung gelöscht wird obwohl nicht nötig.

 

Man kommt bei solchen Überlegungen in den Bereich der "fuzzy logic". Ein bisschen Überlappung sollte toleriert werden. Aber wieviel ist ein bisschen? In der aktuellen Implementation weniger als eine Minute. 60 Sekunden reichen für eine Verdrängung, 59,9 Sekunden noch nicht. Man könnte das Intervall auf "weniger als zwei Minuten" vergrößern. Aber das löst das Problem nicht grundsätzlich. Bei einer Verschiebung um 2 Minuten wäre es wieder da.

 

Zu berücksichtigen sind dabei übrigens vom Anbieter gewollte Überlappungen. Sowas wie

 

17:00 - 18:45 Fußballländerspiel

17:45 - 18:00 Nachrichten

 

ist nach den Spezifikationen zulässig und wird auch mitunter so gemacht - gesehen habe ich das schon in einem australischen DVB-T-Sample. Deshalb markieren DVBViewer und DMS EPG-Einträge nach einer gewissen Zeit als "alt". Nur diese können durch neu eintreffende verdrängt werden, aber keine ebenfalls neu eingetroffenen.

 

Das Problem bei dem Verfahren sind unvollständige EPG-Lieferungen, also hier konkret nur Present/Following ohne eingebettete oder nachfolgende Sendungen. In dem obigen Beispiel würde das Länderspiel als Following-Eintrag die Nachrichten in der Halbzeitpause auf jeden Fall ersatzlos verschwinden lassen. Da hilft dann auch kein toleranteres Überlappungsintervall.

 

Link to comment

Hier ein Fall mit einer Verschiebung von 3 Minuten.

 

Ursprünglicher (alter) 3sat-EPG:

 

Zwischenablage01.png

 

Nach Einschalten der Ersten HD (ECO fehlt):

 

Zwischenablage02.png

 

Nach Einschalten von 3sat:

 

Zwischenablage03.png

Link to comment

Dass unvollständige neue EPG-Einträge auf alte treffen, kann auch passieren, wenn ein Anwender schnell weiterzappt. Dann empfängt der DVBViewer / DMS womöglich nur einen Teil der auf einem Transponder gesendeten EPG-Daten. Daraus resultierende fehlende Einträge bei einer Zeitverschiebung zwischen Alt und Neu sind jedoch nicht so auffällig, weil sie irgendwo mittendrin auftreten.

 

Eine flexiblere Herangehensweise wäre, zu berechnen, wieviel Prozent eines alten Eintrags ein neu hinzukommender Eintrag überdeckt, und dann einen Grenzwert festzulegen, z.B. dass der alte Eintrag ab 0,2 (= 20%) Überdeckung verdrängt wird. Dabei muss man jedoch verschiedene Fälle unterscheiden und sicherstellen, dass ein alter Eintrag auf jeden Fall durch neu hinzukommende ersetzt wird, sofern diese komplett empfangen werden:

  • Neuer Eintrag beginnt vor dem alten oder gleichzeitig: Überdeckter Anteil = (Endzeit(neu) - Startzeit(alt)) / Dauer(alt). Ein negatives Ergebnis bedeutet keine Überschneidung, ein Ergebnis >= 1, dass der alte Eintrag komplett innerhalb des neuen liegt.
  • Neuer Eintrag beginnt nach dem alten:
    • Neuer Eintrag endet vor dem alten  (d.h. er liegt komplett innerhalb des alten). Diesem Fall muss das Ergebnis 1 bzw. 100% zugeordnet werden, nicht die tatsächliche Überdeckung. Sonst könnte eine Reihe kurzer neuer Einträge keinen langen alten Eintrag verdrängen, weil jeder neue Eintrag für sich nicht das erforderliche Maß an Überdeckung erreicht.
    • Neuer Eintrag endet gleichzeitig mit dem alten oder nach ihm: Überdeckter Anteil = (Endzeit(alt) - Startzeit(neu)) / Dauer(alt). Ein negatives Ergebnis bedeutet keine Überschneidung.

Der erste Hauptpunkt behandelt den hier ursprünglich geschilderten Fall, dass ein neuer Following-Eintrag für eine auf später verschobene Sendung auf einen alten nachfolgenden Eintrag trifft. Der zweite Hauptpunkt greift, wenn ein neuer Present-Eintrag für eine auf einen früheren Zeitpunkt verschobene Sendung auf einen vorangehenden alten Eintrag trifft.

 

Findet jemand einen Denkfehler in der obigen Methode?

 

Man muss sich darüber im klaren sein, dass es keine perfekte Lösung gibt. Es wird immer Fälle geben, in denen der Algorithmus wegen Inkonsistenzen zwischen vorhandenen und neu eintreffenden EPG-Daten danebenliegt. Man kann nur versuchen, ihn heuristisch zu optmieren, so dass in möglichst wenigen Fällen Einträge verlorengehen. Eine ähnliche Vorgehensweise ist übrigens erforderlich, wenn der zu einem Aufnahmetimer gehörende EPG-Eintrag nach Zeitverschiebungen wiedererkannt werden soll. Die Sachlage ist dann ein Stück komplizierter, weil Vor- und Nachlauf mit in die Rechnung eingehen.

 

Link to comment
  • 6 months later...

Entschuldige, dass ich mich hier so lange nicht gemeldet habe...

 

Du beschreibst beim zweiten Hauptpunkt im ersten Unterpunkt den Fall, dass mehrere kurze Events ein altes großes verdrängen sollen. Was ist denn, wenn das alte große Event z.B. in zwei neue Events gesplittet wird: Von denen das erste das momentan Following ist, das zweite allerdings nur in der Schedule übertragen wird. Dann würde entsprechend eine größere Lücke im EPG entstehen. Wenn das für diesen Sonderfall hinnehmbar ist, dann passt es ja.

 

Ich frage mich, ob statt zwei IF-Ebenen nicht einfacher wäre, das Modell bzw. die Berechnung wie folgt zu vereinfachen:

duration_common = min(t_end_old, t_end_new) - max(t_begin_old, t_begin_new)

Wenn man diesen Wert dann durch duration_new teilt (und nicht duration_old) und bei > 0,2 den alten Eintrag verwirft, würde man automatisch das alte lange Event rauswerfen, für neue kurze. Im Gegenzug würde ein neues, langes Event dafür sorgen, dass alte kurze beibehalten werden.

 

Wobei sich bei letzterem die Frage stellt: Was ist, wenn man eine kurze Sendung hat (z.B. eine "heute" mit 5min), die sich um 5min nach hinten verschiebt (= keine Überschneidung von neuem mit altem Eintrag). Der Sendungseintrag der vorherigen Sendung (die länger ist, beispielsweise) würde dann NICHT den alten "heute"-Eintrag löschen... Was würde in so einem Fall eigentlich aktuell passieren?

 

Generell frage ich mich, ob man hier tatsächlich mit einem Prozentwert rechnen sollte. Je nach Sendungslänge könnte die dadurch erlaubte Verschiebung dann zu groß/zu klein werden.

Stattdessen könnte man z.B. rechnen:

 

| duration_common - duration_new | < 10min
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...