je genau, mit HandleEitEvent ist es noch nicht drüber, mit HandleEvent ist es drüber, wenn du es da abgreifst landet kannst du aber derzeit nicht verhindern das der VDR es intern mit aufnimmt
Christian
je genau, mit HandleEitEvent ist es noch nicht drüber, mit HandleEvent ist es drüber, wenn du es da abgreifst landet kannst du aber derzeit nicht verhindern das der VDR es intern mit aufnimmt
Christian
Alles anzeigenDas ist ja einfach.
No Way. Hier greift dann für den gesamten Zeitraum das EPG mit der größten Priorität.
Wobei, wenn ein Sender EPG Event von 22:14 (also ursprünglich übereinstimmend mit dem externen Event) auf 23:05 wandert dann kann man davon ausgehen das das Sender EPG korrekt ist (Programmänderung) und das externe veraltet. Klappt natürlich nur wenn der Sender hier die EventID nicht ändert (weil nur dann kann man das verschieben beobachten).
cu
Nachdem die Machbarkeit in der Komunikation mit dem vdr jetzt sichergestellt ist steig ich hier noch einmal ein
Da das Plugin ja alle Daten an Board hat ist ein zusätzliches Plugin wie noepg in dieser Konstellation nicht mehr notwendig. Für Programme bei denen Externes EPG hinterlegt ist wird das interne auf die DB genommen, dann kann man auch gleich die interessanten Programme für die man Senderepg möchte (sind ja meist nur noch 10 oder so) festlegen, die zwar mit auf die DB nehmen aber im selben Schritt durchwinken. Dann hat man nicht für 1200 Sender unnötigen Ballast.
Bei der Entscheidung ext/int ist der Vorschlag mit den Prioritäten natürlich ein guter Punkt: hier soll das Senderepg bis zum nächsten Tag 3 oder 4 Uhr (also max die nächsten 24h) bei Diskrepanzen zwischen Sender/Ext Vorfahrt bekommen um die kurzfristigen Änderungen aufzunehmen. Für die Zeit danach soll uneingeschränk das ext inkl deren tägliche Updates herangezogen werden, also für die nächsten n Tage.
Die Hohe Kunst besteht nun darin einen geeigneten Algorythmus zu entwicken, der Zusammenhängen und damit auch die Diskrepanzen zwischen ext/int aufspürt und daraus bestmöglich ableitet einzelne Events zu ersetzen. Hier testen wir grad ein Sql direkt auf der DB. Es zeigt sich das das sehr gut geht, in einigen Fällen wird jedoch das komplette Nachtprogramm wie Dauerwerbesendung/Infocomercials zusammengefasst, während es auf der anderen Seite in einzelne Sendungen aufgeteilt ist. Hier müssen wir sehen wie man damit umgeht. Ansonsten geht das im SQL schon sehr gut: sehr gute Testkandidaten sind die Regionalsender: für Sendungen im Vorabendprogramm ist das ext das EPG zu eins zusammengefasst , intern dann jedoch den jeweils "richtigen" Lokalteil bekommen. Hier würde das dann quasi jeden Tag "getauscht"
Das man es so wie mans macht in jedem Fall besser machen kann und nie ne 100% Lösung bekommt ist auch klar: aber bestmöglich wär doch schon was
Christian
[...] Bei der Entscheidung ext/int ist der Vorschlag mit den Prioritäten natürlich ein guter Punkt: hier soll das Senderepg bis zum nächsten Tag 3 oder 4 Uhr (also max die nächsten 24h) bei Diskrepanzen zwischen Sender/Ext Vorfahrt bekommen um die kurzfristigen Änderungen aufzunehmen. Für die Zeit danach soll uneingeschränk das ext inkl deren tägliche Updates herangezogen werden, also für die nächsten n Tage. ...
Schön wäre, wenn man zusätzlich noch mit "keywords" arbeiten könnte, die man in einer *.conf hinterlegt.
Mein extEPG liefert z.B. manchmal Einträge wie: "NN" oder "Nach Angabe". Das wäre dann natürlich ein klarer Fall von: "Ersetze diesen Eintrag unbedingt mit dem Sender EPG".
Mein extEPG liefert z.B. manchmal Einträge wie: "NN" oder "Nach Angabe". Das wäre dann natürlich ein klarer Fall von: "Ersetze diesen Eintrag unbedingt mit dem Sender EPG".
IMHO ist es die Aufgabe des Grabbers (d.h. des Softwareteils für diese EPG Quelle) son Müll gleich zu entsorgen. Genau wie EPG Einträge für <Sendepause> oder ähnliches. Felder die als Inhalt "dieses Feld ist leer" haben sollten gleich komplett entfernt werden.
cu
Nun, wer die Aufgabe, den "Müll" zu entsorgen, ist eigentlich wuscht, wobei "Sendepause" ja eigentlich kein Müll ist, denn wenn nichts gesendet wird, gibt es ja auch kein EPG.
wobei "Sendepause" ja eigentlich kein Müll ist, denn wenn nichts gesendet wird, gibt es ja auch kein EPG.
Eben, und dann sollte auch einfach kein EPG da sein. Ein EPG Eintrag für <hier gibts kein EPG> stört die Datenverarbeitung enorm. Sowas sollte gleich am Eingang entsorgt werden anstatt es mitzuschleppen und später per Filter zu behandeln.
cu
zu dem "Mein extEPG liefert z.B. manchmal Einträge wie: "NN" oder "Nach Angabe":
es gibt da ein Problem im bisherigen Plugin (ist schon immer drin) mit der Schleife der Updates: wenn du 8 Tage im vorher einliest wird das updatefile quasi nie wieder geholt. - Also auch dieses Event vom ext nie wieder aktualisiert. Das sollte in Zukuft nicht wieder passieren: wir haben da was entwickelt mit dem wir auf der Website ohne Download den Dateiheader lesen können und nur modifizierte updatefiles herunterladen. Damit haben wir weniger Download als vorher bei max aktuellen Daten. Wir haben festgestellt das bei 8 Tagen Vorlauf quasi jedes File des ext mind. einmal aktualisiert wurde, und genau das wurde bisher nie verabeitet. - Ich denke das ist der Hauptgrund warum xmltv derzeit signifikant bessere Daten liefert.
Sollte es dennoch vorkommen, das am letzten Tag "Nach Angabe" im ext steht würde es eh nach der oben beschriebene Logik weggebügelt, sofern der Sender nicht auch "Nach Angabe" schickt.
Das mit der conf ist vllt dennoch keine blöde Idee um in Einzelfällen auch innerhalb von 24h dem ext den Vorrang zu geben, also gefüllt mit "Dauerwerbesendung" und "Infocomercials"
Christian
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!