Fehlersuche SatIP-EPG-Import (Minutenversatz bei importierten Sendezeiten)

[mbihler]

Ich verwende den aktuellen Media Server, der einen SatIP-Converter (Triax TSS 400) abfragt.

 

Da es immer wieder kleine Fehler (leere Einträge) im KODI-EPG gibt, habe ich etwas recherchiert und denke, dass ich eine mögliche Ursache dafür gefunden habe:

Es sieht so aus, dass der Media-Server sporadisch (ggfs. Rundungsfehler?) die Zeiten vom SatIP-Receiver um eine Minute versetzt importiert.

 

Beispiel:

RTL2 22.05.2022 | Die Welle | 20:14 - 22:26

 

Dieser Eintrag steht so auch in der Timeline im Media Server Web Interface und wird auch so ins KODI importiert.

 

Lt. RTL2 Senderliste wären die richtigen Zeiten für diese Sendung 20:15 - 22:25.

 

Im Media Server Debug-Log (C:\ProgramData\CMUV\DVBViewer\svcdebug.log) sehe ich leider keine Infos bzgl. der empfangenen Daten vom SatIP-Server.

 

Kan man den Logging-Level des Debug-Logs erhöhen bzw. gibt es eine weitere Log-Datei, die ich hier prüfen kann?

[Griga]

vor einer Stunde schrieb mbihler:

Es sieht so aus, dass der Media-Server sporadisch (ggfs. Rundungsfehler?) die Zeiten vom SatIP-Receiver um eine Minute versetzt importiert.

 

Die original gesendeten Zeiten sieht man im TransEdit Analyzer. TransEdit ist ein DVB Scanner & Analyzer, den es im Downloadbereich gibt. Mehr dazu hier.

 

Ein Beispiel: Frauentausch auf RTLZWEI, morgen, 24.05.2022, Start 08:55, Dauer 01:57 - das zeigt der Media Server auf der Seite Sender EPG an. Im TransEdit Analyzer, Abteilung EIT Actual TS, Schedule für RTLZWEI auf Astra 12188 H findet man für die Sendung

 

StartTime = 24.05.2022 06:54:40

Duration = 01:56:38

 

Die gesendete Startzeit ist UTC (ungefähr das gleiche wie Greenwich Mean Time, GMT). Der DMS muss also 2 Stunden addieren, um die deutsche (Sommer-)Zeit zu erhalten. Sichtbar wird hier, dass RTLZWEI sekundengenaue Zeiten sendet. Da DVBViewer und DMS die Sekunden nicht anzeigen (was beim EPG weitgehend sinnlos wäre), runden sie auf ganze Minuten. So kommt es zu Start 08:55, Dauer 01:57 und damit zu der Endzeit = Startzeit + Dauer = 10:52.

 

Die nächste Sendung (auch Frauentausch) beginnt jedoch laut Analyzer um 08:51:18 -> ergibt im DMS 10:51. Aufgrund der Rundung entsteht eine Minute Überlappung zur vorherigen Sendung. So kommt das zustande...

 

[mbihler]

vor 15 Stunden schrieb Griga:

StartTime = 24.05.2022 06:54:40

Duration = 01:56:38

 

Die gesendete Startzeit ist UTC (ungefähr das gleiche wie Greenwich Mean Time, GMT). Der DMS muss also 2 Stunden addieren, um die deutsche (Sommer-)Zeit zu erhalten. Sichtbar wird hier, dass RTLZWEI sekundengenaue Zeiten sendet. Da DVBViewer und DMS die Sekunden nicht anzeigen (was beim EPG weitgehend sinnlos wäre), runden sie auf ganze Minuten. So kommt es zu Start 08:55, Dauer 01:57 und damit zu der Endzeit = Startzeit + Dauer = 10:52.

 

Die nächste Sendung (auch Frauentausch) beginnt jedoch laut Analyzer um 08:51:18 -> ergibt im DMS 10:51. Aufgrund der Rundung entsteht eine Minute Überlappung zur vorherigen Sendung. So kommt das zustande...

 

Ich denke, die Überlappungen würden vermieden, wenn bei der Berechnung der Endzeit die sekundengenauen Werte von Start und Dauer verwendet werden würden und erst am Schluss gerundet wird.

 

Im obigen Beispiel:
EndTime = StartTime + Duration = 06:54:40 + 01:56:38 = 08:51:18 UTC
(Das ergibt dann auch die sekundengenaue Startzeit der nächsten Sendung)

 

Wenn nach dieser Addition gerunden wird, gibt es keine Überlappung:
StartTime gerundet = 06:55 UTC

EndTime gerundet = 08:51 UTC

 

StartTime nächste Sendung gerundet = 08:15 UTC

 

Wäre das ein Vorschlag, der in das nächste Release einfließen könnte :-) ?

[Griga]

vor 21 Minuten schrieb mbihler:

Ich denke, die Überlappungen würden vermieden, wenn bei der Berechnung der Endzeit die sekundengenauen Werte von Start und Dauer verwendet werden würden und erst am Schluss gerundet wird.

 

Denke ich auch. Eine Rundung sollte idealerweise erst bei der Anzeige im Format hh:mm erfolgen. Leider runden DVBViewer und DMS die Zeiten gleich beim Eintreffen der EPG-Daten. Danach ist der Sekundenanteil verloren (den die deutschen Öffentlich-Rechtlichen übrigens nicht verwenden, soweit ich sehen kann). Das war von Beginn an so angelegt, lange bevor ich 2013 nach dem Tod des Hauptentwicklers begonnen habe, mich um die Programme zu kümmern.

 

Die Rundung kann ich nicht einfach eliminieren, weil die EPG-Zeiten an -zig Stellen verwendet werden, nicht nur bei der Anzeige, sondern auch bei vielen internen Vorgängen, die sich womöglich darauf verlassen, ganz zu schweigen von Add-Ons. Die Frage ist, wo sich das wie auswirkt. Sehr vieles müsste überprüft und womöglich korrigiert werden.

 

Da es sich hier nur um eine eher geringfügige Ungenauigkeit handelt, nicht um einen gravierenden Fehler, ist die Motivation, eine derart abrbeitsintensive Änderung in Angriff zu nehmen, nicht besonders groß. Es gibt Dringenderes. In den bevorstehenden 7.2.2 / 3.2.2 Releases wird sich jedenfalls in der Hinsicht nichts tun.

 

[mbihler]

Ich bin selbst SW-Entwickler und verstehe, dass es eine Änderung, die viele Stellen betrifft, aufwändig ist und deshalb gerne vermieden wird.

 

Von meinem Verständnis her sollte die Änderung nur eine Stelle im Programm betreffen:

Die Funktion, in der die EPG-Daten empfangen und gerundet werden.

 

Dass die Zeiten gerundet gespeichert werden, könnte so bleiben wie es ist.

 

Vorschlag:

- Die Berechnung und Rundung der Startzeit bleibt gleich

- Die Endezeit wird anders gerundet:
  Statt: Endezeit = Startzeit_gerundet + Dauer_gerundet
  Neu:  Endezeit = Runden(Startzeit_sekundengenau + Dauer_sekundengenau)

 

Ich hoffe, ich stelle ich mir das zu einfach vor :-) 

[Griga]

Die Endzeit wird nicht sofort beim Empfang von EPG-Daten berechnet und gespeichert (das wäre eine redundante Information), sondern erst später aus bereits gerundeter Startzeit und Dauer ermittelt, wenn sie jemand braucht.

 

[mbihler]

In diesem Fall wäre mein Vorschlag, die gerundete Dauer anders zu berechnen.
 

Ich bin mir recht sicher, dass die Überlappungen durch doppeltes Runden entstehen (Startzeit + Dauer).
Werden beide aufgerundet, wie im obigen Beispiel, ergibt sich eine Laufzeit, die 1 Minute zu lange ist.
 

Neuer Vorschlag:
- Die Berechnung und Rundung der Startzeit bleibt gleich

- Die gerundete Dauer wird über die sekundengenaue Endezeit berechnet:

  Statt: Dauer_gerundet = Runden(Dauer_sekundengenau)

  Neu:  Ende_gerundet = Runden(Start_sekundengenau + Dauer_sekundengenau)
            Dauer_gerundet = Ende_gerundet - Start_gerundet
 

Obiges Beispiel:

Startzeit = 24.05.2022 06:54:40
Dauer = 01:56:38

=> Berechnung der Dauer

Ende_gerundet = Runden(06:54:40 + 01:56:38) = Runden(08:51:18) = 08:51
Dauer_gerundet = 08:51 - 06:55 = 1:56
(statt wie bisher 1:57)

[Griga]

vor 2 Stunden schrieb mbihler:

Neuer Vorschlag:
- Die Berechnung und Rundung der Startzeit bleibt gleich

- Die gerundete Dauer wird über die sekundengenaue Endezeit berechnet:

  Statt: Dauer_gerundet = Runden(Dauer_sekundengenau)

  Neu:  Ende_gerundet = Runden(Start_sekundengenau + Dauer_sekundengenau)
            Dauer_gerundet = Ende_gerundet - Start_gerundet

 

Die Idee sieht gut aus. Auf den Ansatz bin ich noch gar nicht gekommen. Er lässt sich leicht realisieren und erzeugt nur einen geringfügigen Mehraufwand von einer Fließkomma-Addition und -Subtraktion (mehr dazu hier) pro eintreffendem EPG-Datensatz. Ich habe es kurz probiert, und die Zeiten für RTLZWEI sehen jetzt alle stimmig aus. Da es wahrscheinlich keine Risiken und Nebenwirkungen im weiterverarbeitenden Gewerbe erzeugt, könnte das so noch ins bevorstehende 7.2.2 Release mit rein.

 

Danke für den Beitrag