Feinheiten der neunen EPG Schnittstelle, Event aktuallisieren lassen ohne Text zu ändern?

3PO · 13. Mai 2012

Zitat von CKone

[...] das externe EPG soll vom Senderepg im Fall von aktuellen Programmänderungen ersetzt werden, nicht andersrum. ...

Und genau hier ist doch das Problem.
Wer, oder was, entscheidet nun, welcher EPG Eintrag der Richtige ist?

CKone · 13. Mai 2012

das ist ne Frage die separat im Plugin zu lösen ist, also das Plug entscheidet.

Um mal eben 1000 Einträge abzugleichen kannst du bequem wie bei Serientimer die Levenshtein Methode oder was anderes schlaues nehmen, schauen ob es signifikant abweicht und dann handeln oder nicht. Das schaffst du bequem in nem Bruchteil einer Sekunde. Kannst du quasi als ne Art Housekeeping Job auf der DB alle 5 Minuten machen.

Das ist aber ne ganz andere Baustelle, mir gehts erst mal um die grundsätzliche Machbarkeit eines Designs in Bezug auf die Kommunikation mit dem VDR.

Christian

Keine_Ahnung · 13. Mai 2012

Zitat von C-3PO

Wer, oder was, entscheidet nun, welcher EPG Eintrag der Richtige ist?

Man muss einfach für die verschiedenen Quellen Prioritäten festlegen. Wobei eine kurzfristige Änderung des Sender EPG dessen Priorität erhöhen sollte.

Aber das wird man eh niemals wirklich befriedigend lösen können, dafür bauen die alle zu viel Müll. Weder Sender EPG noch externes EPG sind wirklich 100%ig.

cu

3PO · 13. Mai 2012

OK, dann bleibt aber noch das Problem mit dem Sendungsbegin.

extEPG 20:15 --> SenderEPG 20:14

oder bei Verschiebungen, wie z.B. bei live Events:

extEPG 22:15 --> SenderEPG 23:05

Wie willst Du das in den Griff bekommen?

Keine_Ahnung · 13. Mai 2012

Zitat von C-3PO

OK, dann bleibt aber noch das Problem mit dem Sendungsbegin.

extEPG 20:15 --> SenderEPG 20:14

Das ist ja einfach.

Zitat von C-3PO

oder bei Verschiebungen, wie z.B. bei live Events:

extEPG 22:15 --> SenderEPG 23:05

Wie willst Du das in den Griff bekommen?

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

CKone · 13. Mai 2012

Wie gesagt, das ist ein separates Thema, da kann man viel drüber philosophieren, manchmal macht aber auch Versuch klug. - Ich würde auch bis zum letzten Tag immer noch hoffen das mir der ext. Datenprovider noch ein passendes Updatefile schickt - und um die Menge der Testkandidaten klein zu halten immer nur Events der nächsten 24h mit einer zu definierenden Methode auf "Herz und Nieren" auf das Sender EPG gegenprüfen. Es geht um kurzfristige Programmänderungen, langfristige kommen durchs Updatefile.

Mich interessiert aber egtl ob so ein Grundgerüst der Kommunikation mit den vorhandenen Methoden im VDR theoretisch möglich ist, oder ob da irgendwo der Schuh an den Esssentials drückt?

Sprich:
- kann ich dem VDR ext epg unterjubeln? => geht wie immer
- kann ich ein bestimmtes event aus EPG und epg.data entfernen
- kann ich mit dem epghandler oder anders das Senderepg abgreifen ohne das es in der epg,data landet
- hab ich ne benötigte Methode vergessen?

Wenn ja hätte ich einen Plan...

Christian

3PO · 13. Mai 2012

Zitat von CKone

- kann ich mit dem epghandler oder anders das Senderepg abgreifen ohne das es in der epg,data landet
- hab ich ne benötigte Methode vergessen?

Die Frage ist halt, ob man bei Verwendung von extEPG nicht ganz auf die epg.data verzichten sollte?

Was ich damit meine ist, ein Plugin zu basteln, das das komplette EPG handling übernimmt und die Daten in einer Datenbank verwaltet.

CKone · 13. Mai 2012

Zitat von C-3PO

Die Frage ist halt, ob man bei Verwendung von extEPG nicht ganz auf die epg.data verzichten sollte?

ja, das wäre schon ideal, fänd ich auch besser - hätte aber zwei Probleme:
zum einen wärst du wieder an dem Punkt an dem nur das im EPG angezeigt wird was der epghandler anfragt. Deshalb den Workaround alles wie bisher in die epg.data zu schieben und das look&feel wie immer mit 10 Tagen Vorausschau zu erhalten. Wie ich Jörg und auch Lars verstanden habe geht das ohne diese Krücke mit dem derzeitige epghandler im VDR nicht ohne Kombination mit der alten Methode...

Der zweite Punkt wäre das du dann alles in Echtzeit verarbeiten musst.

Ich finds aber gar nicht so schlimm wenn ein Event sich erst nach 5 Minuten ändert, das Ding dafür aber schnell wie die Sau ist!

Christian

3PO · 13. Mai 2012

Zitat von CKone

[...] hätte aber zwei Probleme:
zum einen wärst du wieder an dem Punkt an dem nur das im EPG angezeigt wird was der epghandler anfragt. ...

Dann müsste halt das Plugin das SenderEPG eben auch in die DB schreiben.

Zitat von CKone

[...] Der zweite Punkt wäre das du dann alles in Echtzeit verarbeiten musst. ...

Das sollte bei den heutigen Mehrkern CPUs doch kein Problem sein, older?

CKone · 13. Mai 2012

Zitat von C-3PO

Dann müsste halt das Plugin das SenderEPG eben auch in die DB schreiben.

Davon hast dus aber nicht im EPG Zugriff des VDR. Du musst jedes einzelne Event dem vdr bekantmachen, entweder der Sender macht es wie bei xmltv, oder du musst halt wie von Lars beschrieben die cEvents selber reinpumpen. - Irgendwie müssen die da rein, ob du nun die epg.data schreiben lässt oder das nur im Speicher löst macht keinen Unterschied.

Zitat von C-3PO

Das sollte bei den heutigen Mehrkern CPUs doch kein Problem sein, older?

Sehen wir wenn wir soweit sind, es ist immer gut wenn man wählen kann, hier ob man es sysnchron oder asynchron macht. Aber alles zu seiner Zeit...

Christian

mini73 · 13. Mai 2012

Moin!

Wenn das Sender-EPG nur eine weitere Quelle sein soll, würde ich mit einem EpgHandler per HandleEitEvent das Sender-EPG abfangen und in die Datenbank schreiben. Wenn man dann "true" zurückgibt, kümmert sich der vdr nicht weiter um das EPG und schreibt es auch nicht in seine interne Strukturen inkl. epg.data.
Dann hat das Plugin noch einen anderen Thread, der dann aus den diversen EPG-Quellen das gewünschte EPG zusammenmischt und in den vdr pumpt per Injektion von cEvent-Objekten in den passenden cSchedules.

Ist eigentlich ganz sauber getrennt. Um die epg.data (== cEvent/cSchedules) kommt man nicht herum, denn da holt sich der vdr die Timer her usw. Da braucht man auch gar nicht anfassen, das ist schon ausreichend gut genug so.

Lars.

CKone · 13. Mai 2012

Moin

danke Lars, dann gehen wir das mal zum Testen so an.

Christian

Keine_Ahnung · 14. Mai 2012

Hab mal etwas weiter getestet, die Components (X E 01 foo bar) zum speichern der Metainfos war ne nette Idee, aber die überleben leider ein EIT Update nicht

Ich nutze jetzt nen Stringflag in der Beschreibung. Und ich tue mich mit C unheimlich schwer, könnte mir evtl. jemand von denen denen es leichter fällt verraten wie ich aus Event->Description() den String "\nmodEPG: " bis zum Ende oder zum nächsten (evtl. vorhandenen) "\n" löschen kann?

Das ist so mein aktueller Basteltest (geht erst mal nur darum rauszufinden ob es so funktionieren könnte)

Code

bool cTable0Handler::SetEventID(cEvent *Event, tEventID EventID)
{
//   const cComponents *Components = Event->Components();
//   if (Components) {
//     for (int i = 0; i < Components->NumComponents(); i++) { 
//       const tComponent *p = Components->Component(i); 
//       if ((p->stream == 0x0E) && (p->type == 0x01)) {
//         esyslog("test:SetEventID %s", Event->Title());
//         return true;
//       }
//     }
//   }
//   return false;
  const char *delim = "\nmodEPG: ";
  const char *test = Event->Description();
  if ( ! test ) { return false; }
  const char *e = strstr(test, delim);
  if ( e ) {
    //esyslog("test:SetEventID %s", Event->Title());
    Event->SetEventID(EventID);
    return true;
  }
  return false;
}

Alles anzeigen

Hier müsste halt "\nmodEPG: " aus der Beschreibung gelöscht werden wenn sich alte und neue EventID unterscheiden.

cu

mini73 · 15. Mai 2012

Moin!

Letztendlich musst du in deinem ersten Suchergebnis wieder nach "\n" suchen.
Wenn du ein Ergebnis findest, dann setzt du an die Stelle des ersten Suchergebnisses eine "\0" und erstellst mit snprintf (am besten die Hilfsfunktion aus der vdr-Klasse cString nehmen) einen neuen String mit dem Format "%s%s", wobei der erste der Original-String ist und der zweite das zweite Suchergebnis.
Wenn du kein Ergebnis findest, dann trotzdem an die Stelle des ersten Suchergebnisses eine "\0" setzen und nur diesen String kopieren.

Da man sich schnell ins Knie schießen kann, wenn man in C mit Strings und Speicher rumhantiert, würde ich dir raten, konsequent, die vdr-cString-Klasse zu verwenden.

Code

cString desc( Event->Description);

Einfach mal in tools.h nachsehen.

Oder du schwenkst auf die C++-STL um und benutzt std::string.

Lars.

ludi · 15. Mai 2012

Zitat von mini73

Wenn das Sender-EPG nur eine weitere Quelle sein soll, würde ich mit einem EpgHandler per HandleEitEvent das Sender-EPG abfangen und in die Datenbank schreiben. Wenn man dann "true" zurückgibt, kümmert sich der vdr nicht weiter um das EPG und schreibt es auch nicht in seine interne Strukturen inkl. epg.data.
Dann hat das Plugin noch einen anderen Thread, der dann aus den diversen EPG-Quellen das gewünschte EPG zusammenmischt und in den vdr pumpt per Injektion von cEvent-Objekten in den passenden cSchedules.

Ich finde es wirklich großartig, was ihr hier zu machen versucht. 8-)

mini73 · 15. Mai 2012

Moin!

Zitat von ludi

Ich finde es wirklich großartig, was ihr hier zu machen versucht. 8-)

Danke, aber ich bin ja nur Berater...
Aber ansonsten würden "wir" es ja auch nicht machen, wenn es nicht großartig wäre!

Lars.

Keine_Ahnung · 15. Mai 2012

Zitat von mini73

Letztendlich musst du in deinem ersten Suchergebnis wieder nach "\n" suchen.
Wenn du ein Ergebnis findest, dann setzt du an die Stelle des ersten Suchergebnisses eine "\0" und erstellst mit snprintf (am besten die Hilfsfunktion aus der vdr-Klasse cString nehmen) einen neuen String mit dem Format "%s%s", wobei der erste der Original-String ist und der zweite das zweite Suchergebnis.
Wenn du kein Ergebnis findest, dann trotzdem an die Stelle des ersten Suchergebnisses eine "\0" setzen und nur diesen String kopieren.

Hm, ich hatte gehofft das geht irgendwie einfacher Aber danke, ich denke ich weiss jetzt wos hingeht.

Zitat von mini73

Oder du schwenkst auf die C++-STL um und benutzt std::string.

Wobei ich hier wieder nie weiss was nun den Pointer direkt manipuliert oder wenn ne Kopie erstellt wird (irgendwie muss man ja nen Pointer zum std::string bringen), ruck zuck hat man da nen Memleak drin Bei solchen Sachen bin ich da sehr wackelig unterwegs, in Pascal ist das doch alles sehr viel einfacher

Allerdings habe ich da jetzt nochmal drüber nachgedacht und beschlossen das Textflags im EPG Text irgendwie doch sehr pfushig sind. Ich werde klaus nen Patch schicken der SetComponents im epghandler mit aufnimmt, dann kann man das sauber lösen (halt mit den oben auskommentierten Code).

cu

mini73 · 15. Mai 2012

Moin!

Zitat von Keine_Ahnung

Hm, ich hatte gehofft das geht irgendwie einfacher Aber danke, ich denke ich weiss jetzt wos hingeht.

Es ist eben C...

Der Konstruktor von cString erstellt eine Kopie und gibt sie auch wieder im Destruktor frei, wenn man beim Parameter "TakePointer" false (default-Wert) übergibt.
Bei "true" übernimmt das cString-Objekt den Pointer. Das ist ganz praktisch, wenn man per strdup o.ä. eine Kopie erstellt hat. Den Pointer übergibt man dann an cString(pointer, true) und sobald der Destruktor aufgerufen wird, wird der Speicher freigegeben. Dann muss man nicht selbst an diversen Stellen "free" aufrufen, falls man mehrere Return-Pfade in der Funktion hat.

Zitat von Keine_Ahnung

Ich werde klaus nen Patch schicken der SetComponents im epghandler mit aufnimmt, dann kann man das sauber lösen (halt mit den oben auskommentierten Code).

Oder so...

Lars.

CKone · 18. Mai 2012

Zitat von mini73

Moin!

Wenn das Sender-EPG nur eine weitere Quelle sein soll, würde ich mit einem EpgHandler per HandleEitEvent das Sender-EPG abfangen und in die Datenbank schreiben. Wenn man dann "true" zurückgibt, kümmert sich der vdr nicht weiter um das EPG und schreibt es auch nicht in seine interne Strukturen inkl. epg.data.
Dann hat das Plugin noch einen anderen Thread, der dann aus den diversen EPG-Quellen das gewünschte EPG zusammenmischt und in den vdr pumpt per Injektion von cEvent-Objekten in den passenden cSchedules.

Ist eigentlich ganz sauber getrennt. Um die epg.data (== cEvent/cSchedules) kommt man nicht herum, denn da holt sich der vdr die Timer her usw. Da braucht man auch gar nicht anfassen, das ist schon ausreichend gut genug so.

Lars.

Alles anzeigen

Es wird hierzu in der nächsten Version des VDR eine Erweiterung des epghandler geben, welche es ermöglicht dem vdr das Event nach durchlaufener eit-Verarbeitung zu entnehmen, jedoch ohne es gleichzeitig in seine weiteren internen Strukturen und der epg.data aufzunehmen. Letzteres ist so bisher nur mit HandleEitEvent möglich, hier gibt der vdr jedoch kein formatiertes EPG sonden nur Rohdaten aus.

Christian

Keine_Ahnung · 18. Mai 2012

Zitat von CKone

Letzteres ist so bisher nur mit HandleEitEvent möglich, hier gibt der vdr jedoch kein formatiertes EPG sonden nur Rohdaten aus.

Du meinst damit das dort das epg bugfixing noch nicht drüber war? Oder gibts da noch andere Unterschiede?

cu

Feinheiten der neunen EPG Schnittstelle, Event aktuallisieren lassen ohne Text zu ändern?

Jetzt mitmachen!

Teilen