mbihler Posted May 23, 2022 Share Posted May 23, 2022 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? Quote Link to comment
Griga Posted May 23, 2022 Share Posted May 23, 2022 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... Quote Link to comment
mbihler Posted May 24, 2022 Author Share Posted May 24, 2022 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 :-) ? Quote Link to comment
Griga Posted May 24, 2022 Share Posted May 24, 2022 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. Quote Link to comment
mbihler Posted May 24, 2022 Author Share Posted May 24, 2022 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 :-) Quote Link to comment
Griga Posted May 24, 2022 Share Posted May 24, 2022 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. Quote Link to comment
mbihler Posted May 26, 2022 Author Share Posted May 26, 2022 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) 1 Quote Link to comment
Griga Posted May 26, 2022 Share Posted May 26, 2022 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.