[Announce] VDR Plugin EPG2VDR 0.0.1

Zitat von CKone

ja, denken wir das man auch gerade die epg.data nicht so ultra fett machen sollte, ganz unabhänging von epg Plugins.
dann mach blacklist aus und nimm nur die als 000:vdr in die channelmap auf bei denen du die Serien gemischt haben willst
Christian

du meinst sicher blacklist AN

iNOB, du musst es nicht extra auf die channles.conf beschneiden, der VDR verfügt ohnehin nur über das Sender EPG der eingestellten Kanäle. Betreibt man mehrere VDR mit unterschiedlicher channels.conf ist es ggf. sinnvoll mehr als einem VDR das schreiben der Datenbank mit dem Sender EPG zu erlauben:
Plugin Setup "Update DVB EPG Database = auto|yes|no"

CKone & horchi

Super Sache, ich freue mich wirklich für Euch, das Ihr Euer Wunschplugin endlich fertig gebracht habt ...

===

Auf den ersten Blick finde das Konstrukt recht komplex, das wird Steffen bestimmt ausgesprochen gut gefallen, ;D, aber die drei, vier Abhängigkeiten ausserhalb des VDR bergen meiner Meinung nach einige Unbekannte. Mal sehen wie sich das im deftigen Betrieb im Sinne der Stabilität und Dienste-Verfügbarkeit gibt ...

Soweit ich das sehe liegen externe EPG Infos eher immer als XML Daten vor, die Ihr nicht so verarbeitet, ok, aber ein Grabber wird komplexer, richtig? Ist das so komplex, das man fast schon sein eigenes EPG Plugin für den VDR bauen könnte?

Und ein Punkt, verzeiht mir, ist mir völlig unverständlich, die Entscheidung das das Plugin erst ab VDR 2.1.1 läuft. VDR 2.0.0/2.0.2 ist erst einige Monate alt und daher aktuell, Plugins sollten also auch damit ungepatcht funktionieren. Wäre die Lücke so große wie zuletzt bei VDR 1.6.0 zu VDR 1.7.4x/2.0.0, würde ich das noch verstehen, wobei die Lücke eher andere Gründe hatte.

Ich mach mir keine Illusionen, das einige Trolle mich für diese Punkte wieder beschimpfen, aber ich möchte keineswegs Euer Plugin schlecht reden, im Gegenteil!

===

Regards
fnu

Zitat von fnu

Und ein Punkt, verzeiht mir, ist mir völlig unverständlich, die Entscheidung das das Plugin erst ab VDR 2.1.1 läuft. VDR 2.0.0/2.0.2 ist erst einige Monate alt und daher aktuell, Plugins sollten also auch damit ungepatcht funktionieren. Wäre die Lücke so große wie zuletzt bei VDR 1.6.0 zu VDR 1.7.4x/2.0.0, würde das noch verstehen, wobei die Lücke eher andere Gründe hatte.

da hast du absolut recht, leider war die Lücke im Handler schwierig und nicht ohne gebastel zu umschiffen, daher der Patch. Hintergrund der Handler im VDR sieht ein geliefertes EPG Segment als Transaktion auf die er zum aufräumen geschlossen zugreifen muss (liegt an der Art der Lieferung vom Sender) bot jedoch keine die vielen daraus resultierenden Einzel-Aufrufe kapselnde Methode zum externen Handler. Die dafür benötigte DB Transaktion bis zum nächsten Segment offen zu halten würde Konflikte (locks) mit anderen Zugriffen resultieren.

Zitat von fnu

Mal sehen wie sich das im deftigen Betrieb im Sinne der Stabilität und Dienste-Verfügbarkeit gibt ...

Das Ding läuft schon seit Monaten stabil, da sehe ich keine Probleme.

Zitat

Und ein Punkt, verzeiht mir, ist mir völlig unverständlich, die Entscheidung das das Plugin erst ab VDR 2.1.1 läuft. VDR 2.0.0/2.0.2 ist erst einige Monate alt und daher aktuell, Plugins sollten also auch damit ungepatcht funktionieren. Wäre die Lücke so große wie zuletzt bei VDR 1.6.0 zu VDR 1.7.4x/2.0.0, würde das noch verstehen, wobei die Lücke eher andere Gründe hatte.

Dem VDR fehlten gewisse EPG Handler Schnittstellen, die nun erst im 2.1.1 in den VDR gewandert sind.

Zitat

- Added Begin/EndSegmentTransfer() to the EPG handler interface (thanks to Jörg Wendel).

Zitat von fnu

erst ab VDR 2.1.1 läuft. VDR 2.0.0/2.0.2 ist erst einige Monate alt und daher aktuell

Es gibt da noch eine minimale Ergänzung der EpgHandler-API im vdr, die ein Verpacken der SQL-Abfragen in Transaktionen ermöglicht. Ich kann mir gut vorstellen, dass diese Erweiterung es evtl. auch in den vdr 2.0.3 schafft.

Lars.

Zitat von fnu

Soweit ich das sehe liegen externe EPG Infos eher immer als XML Daten vor, die Ihr nicht so verarbeitet, ok, aber ein Grabber wird komplexer, richtig? Ist das so komplex, das man fast schon sein eigenes EPG Plugin für den VDR bauen könnte?

So ein Grabber ist recht schnell gemacht, der epgd und die Grappber verwenden ein XSLT um das XML auf das internen erwartete Format anzupassen, hat man dies ist der Grabber sofern die Quelle nicht ganz anders gestrickt ist in 1-2 Tagen implementiert.

Zitat von mini73

Es gibt da noch eine minimale Ergänzung der EpgHandler-API im vdr, die ein Verpacken der SQL-Abfragen in Transaktionen ermöglicht. Ich kann mir gut vorstellen, dass diese Erweiterung es evtl. auch in den vdr 2.0.3 schafft.

Die 2.0 ist *stable*, da sollte es eigentlich keine API-Änderungen mehr geben.

Klaus

Zitat von horchi

da hast du absolut recht, leider war die Lücke im Handler schwierig und nicht ohne gebastel zu umschiffen, daher der Patch.

Aber irgendwas ist doch immer, oder? VDR 2.0.x ist das Maß der Dinge, nicht die erste Version eines neuen Entwickler-Zweigs ...

Die Entscheidung macht IMHO nur dann Sinn, wenn der Patch in 2.0.3 einfliesst.

Zitat von TheChief

Das Ding läuft schon seit Monaten stabil, da sehe ich keine Probleme.

Schön das Deine Installation die Referenz für alle anderen ist ...

Regards
fnu

Ich bin ja nicht der einzige, der am Testen war. Aber erstmal wieder einen schnippischen Kommentar da lassen.

Zitat von kls

Die 2.0 ist *stable*, da sollte es eigentlich keine API-Änderungen mehr geben.

Ok, kein Problem, war ja auch nur geraten, weil der Patch doch sehr übersichtlich ist.

Macht für yavdr aber keinen Unterschied, ein Patch mehr oder weniger stört dann auch nicht...

Lars.

Habs auch laufen auf 2.0.2 und teste nun... Ein Server (wie angezeigt HP N40L) macht hier tatsächlich immer mehr Sinn. Habs derzeit lokal laufen. Einfach zu installieren in Zusammenarbeit mit dem 'db_helper' - Danke für die Arbeit ans Team!

Zitat von Taipan

Habs auch laufen auf 2.0.2 und teste nun... Ein Server (wie angezeigt HP N40L) macht hier tatsächlich immer mehr Sinn. Habs derzeit lokal laufen. Einfach zu installieren in Zusammenarbeit mit dem 'db_helper' - Danke für die Arbeit ans Team!

Freut mich das es rennt

Zitat von Taipan

Ein Server (wie angezeigt HP N40L) macht hier tatsächlich immer mehr Sinn.

Nicht mehr wirklich, aktuell ist der N54L angesagt. Mehr Power ohne deutlich mehr Stromverbrauch und preislich tut sich da kaum was.

Gerald

Für mysql sollte eher mehr RAM als CPU Leistung vorhanden sein. Mit 128 oder 256 MB würde ich es sein lassen. Hab diesbezüglich mit mysql in XEN-Domus einige Erfahrung im Laufe der Jahre sammeln können, z.B. mit Zarafa oder Wordpress die ebenfalls mysql als DB benutzen. Aktuell bekommt Wordpress unter XEN auch nur 512MB zugewiesen und läuft damit recht passabel.

Im Vergleich zu meinem VDR (Core2Duo + 2 GB RAM) ist der Raspi um den Faktor 10-11 langsamer. Aber solange das meinen VDR nicht ausbremst ist mir das egal. Ich mach mir eher Gedanken über das ständige Rumgeschreibe auf die SD-Karte. Das ist auf Dauer sicher nicht gesund. Wenns in die Hose geht kommt der Kram einfach in eine XEN-Domu.

Gruß
iNOB

der an meiner Pellets Heizung:

root@raspberrypi:~# free -mot
             total       used       free     shared    buffers     cached
Mem:           438        149        288          0         45         76
Swap:           99          0         99
Total:         538        149        388

Zitat von CKone

wieviel Ram hatt denn jetzt der Raspi: 512Mb?

Die Variante B hat 512 MB, die Variante A 256 MB (und keinen Ethernet-Port).
Wenn man das ganze sowieso nur als Server nutzt, wäre evtl. auch ein Cubieboard besser geeignet (wegen bis zu 1 GB Ram und SATA-Port)