EPG zu DB Plugin - Brainstorming

magicamun · 8. März 2013

ja - ich hatte das tableid-plugin genommen. dann hab ich es aber ja "richtig" gemacht - die tableid schreibe ich so, wie sie bei "mir" ankommt

Keine_Ahnung · 8. März 2013

Zitat von magicamun

Kann mir noch jemand den Sinn hinter TableID erklären?

Gib mal bei Google "ETSI EN 300" ein, da findest du die PDF die das alles erklären.

Ist alles IMHO ein wenig überkompleziert, und der VDR macht da auch spezielle Sachen mit. Z.B. überschreiben die Now&Next EPG Infos (AFAIK nen anderer Datenstrom) im VDR die normalen EPG Infos mit ner speziellen Table ID.
Das ist auch insofern relevant das bei einigen Sendern bestimmte Informationnen nur in den Now&Next Infos stecken aber nicht in den normalen EPG Daten.

cu

magicamun · 8. März 2013

Kurzer Zwischenstand:

Pluginname : "epg2db", derzeit Mysql only, Argumentliste:

Code

...
epg2db (0.0.1) - EPG handler to store events in database


  -h HOSTNAME --host=HOSTNAME  	Hostname to connect to
                               	(default: (localhost)
  -d DATABASE --database=DATABASE  Database-Name
                               	(default: (vdr)
  -u USERNAME --username=USERNAME  Username for connection
                               	(default: (vdr)
  -p PASSWORD --password=PASSWORD  Password for connection
                               	(default: (vdr)
  -o ORIGIN   --origin=ORIGIN  	Origin to write to Database
                               	(default: (HOSTNAME/epg2db)
  -P PRIORITY --priority=PRIORITY  Priority for this client
                               	(default: (100)
...

Alles anzeigen

Die obigen Argumente dürften bis auf origin und priority selbsterklärend sein. Priority dient dazu konfigurieren zu können wer "gewinnt" - Nur Eintrage mit einer gleichen oder niedrigeren (höherer Wert) Prio werden duch diesen Client überschrieben. Beim Insert wird diese prio mit eingefügt.

Origin - damit man pro Event auch sehen kann woher kams denn - welcher Client hat den Event zuletzt angefasst. - Mit geeigneten anderen Anwendungen kann man ja "frei" auf der DB rumwerkeln - sollte halt sauber seine Spuren hinterlassen. Default für origin ist rechnername/epg2db.

Tabelle event:

Code

create table event (
   channelid varchar(32),
   eventId integer,
   tableID integer,
   version integer,
   runningStatus integer,
   parentalRating integer,
   title text,
   shortText text,
   description text,
   startTime integer,
   duration integer,
   vps integer,
   seen integer,
   origin varchar(128),
   priority integer,
   channelname varchar(128),
   primary key (channelid, eventId)
  ,key (eventid)
  ,key (channelname)
);

Alles anzeigen

Da fehlen noch kleinigkeiten wie Components im Modell etc. auch die datentypen (varchar, text) mögen sich nochmal leicht ändern - für den Proof of Concept tuts das derweil

Ich bin mir schon ziemlich sicher, wo ich ansetze um den EPG zyklisch einzufügen -,ist die n. Aktion
Und damit das ganze auch von aussen zu triggern ist, wird es noch eine SVDRP-Schnittstelle zum antriggern des "EPG-Einfügen" geben. damit können dann externe Anwendungen zunächst die Datenbank befüttern und dann die angedockten vdr's der Reihe nach anstoßen sich den EPG neu zu ziehen.

Ach so - dies noch: Sollte die verbindung zur DB zwischendrin abrauchen, so versucht das plugin den connect vor einer DB-Aktion wieder herzustellen - selbstheilend quasi.

Hab ich was übersehen?

Moorviper · 9. März 2013

schaue doch einfach wie die es bei reel machen da läuft das soweit ich mich erinnere auch über ne datenbank warum das rad immer neu erfinden wenn es das schon fertig gibt

gda · 9. März 2013

Zitat von Moorviper

schaue doch einfach wie die es bei reel machen da läuft das soweit ich mich erinnere auch über ne datenbank warum das rad immer neu erfinden wenn es das schon fertig gibt

Weil es Spaß macht etwas selber zu machen, könnte ich mir vorstellen.

Gerald

magicamun · 9. März 2013

nach einer Nacht sieht die db so aus (gefüttert von vdr#2 und vdr#3) - den Büchsen mit jeweils nur einer Karte. Beide liefen mit der gleichen Priorität:

Code

mysql> select count(*), origin, priority from event group by origin, priority;
+----------+---------------+----------+
| count(*) |    	origin    	| priority |
+----------+---------------+----------+
| 	5865 | amun/epg2db   |  	 	100 | 
| 	6347 | anubis/epg2db |  	 	100 | 
+----------+---------------+----------+
2 rows in set (0.06 sec)


mysql>

Alles anzeigen

mini73 · 9. März 2013

Moin!

Zitat von magicamun

Ich bin mir schon ziemlich sicher, wo ich ansetze um den EPG zyklisch einzufügen -,ist die n. Aktion
Und damit das ganze auch von aussen zu triggern ist, wird es noch eine SVDRP-Schnittstelle zum antriggern des "EPG-Einfügen" geben. damit können dann externe Anwendungen zunächst die Datenbank befüttern und dann die angedockten vdr's der Reihe nach anstoßen sich den EPG neu zu ziehen.

Da solltest du dir echt mal xmltv2vdr ansehen. Auch wenn es Spaß bringt, sowas zu entwickeln, es nützt ja nichts, wenn man ein dutzend Plugins hat, die alle EPG importieren, aber inkompatibel zueinander sind. Insbesondere, wenn man für verschiedene Kanäle unterschiedliche Quellen benutzen möchte.

Sinnvoll wäre hier, einen xmltv2vdr-Grabber zu schreiben, der aus der Datenbank entsprechende XML-Dateien generiert, die xmltv2vdr verarbeiten kann. Dann brauchst du dich nicht darum zu kümmern, was die Nutzer mit dem EPG anfangen wollen. Ob sie das DVB-EPG komplett ersetzen oder nur Teile davon mischen oder oder oder... Ist alles schon in xmltv2vdr gelöst.

Lars.

magicamun · 9. März 2013

Verstehe ich noch nicht:

wenn xmltv2vdr (EPG-)Daten in Form von in xmltv-Format vorliegendem Schema IN EINEN VDR importiert löst das mein Thema nicht (denke ich).

Ich will den EPG (zunächst mal ohne xmltv-gepimpte) Zusätze meiner VDR's synchron halten - und das mit wenig bis gar keinem Zutun.

Entweder die Dokus zu xmltv2vdr erzählen nur die Hälfte oder xmltv2vdr kann das extrahieren und mischen nicht.

Das Plugin schaue ich mir im Quellcode dennoch an.

mini73 · 9. März 2013

Moin!

xmltv2vdr importiert EPG aus XML-Dateien. Vorher diese XML-Dateien kommen, wird durch Grabber geregelt. Diese kann xmltv2vdr regelmäßig aufrufen und dafür auch z.B. den vdr aufwecken.
Es gibt Grabber für epgdata.com und auch für andere Quellen.
xmltv2vdr kann nun entweder das vorhandene DVB-EPG mit Infos aus den externen Quellen aufbessern (z.B. Episodentitel) oder das DVB-EPG komplett ersetzen.

Dein Plugin schreibt also einfach das DVB-EPG in die Datenbank, ein xmltv2vdr-Grabber erzeugt aus der Datenbank eine xmltv-Datei, die xmltv2vdr dann wieder importieren kann. In welcher Form, bleibt dem Nutzer überlassen (mischen, ersetzen usw.). Du würdest dann den Modus "ersetzen" nehmen.

Aber es kann schon sein, dass für deinen speziellen Fall (EPG synchronisieren) xmltv2vdr nicht das Passende ist.

Lars.

TheChief · 9. März 2013

Zitat von magicamun

Verstehe ich noch nicht:

wenn xmltv2vdr (EPG-)Daten in Form von in xmltv-Format vorliegendem Schema IN EINEN VDR importiert löst das mein Thema nicht (denke ich).

Ich will den EPG (zunächst mal ohne xmltv-gepimpte) Zusätze meiner VDR's synchron halten - und das mit wenig bis gar keinem Zutun.

Entweder die Dokus zu xmltv2vdr erzählen nur die Hälfte oder xmltv2vdr kann das extrahieren und mischen nicht.

Das Plugin schaue ich mir im Quellcode dennoch an.

Alles anzeigen

Na da tuts aber auch epgsync. Bei mir importiert mein Server EPG von extern und die Clients holen sich die Daten per epgsync.

magicamun · 9. März 2013

wie ich eingangs schon erwähnte - wenn epgsync nur per OSD getriggert wird oder beim Start - dann ist mir das zu wenig.

EPG zu DB Plugin - Brainstorming

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema