#23
Beitrag
von Innuendo » Mo 07 Mai 2007, 13:18
funktionieren könnte es schon, auch ein epg speicherpfad im var ...
dafür müßte aber so manches angepasst werden, damit es überhaupt brauchbar ist:
1. die aktuelle testecke von nirvana "sectionsd goes table" mit epg langtext in stunden müsste auf "wenige" stunden begrenzt werden. mehr als 4 oder 5 tage im vorraus bei max 3000 events wäre wahrscheinlich nicht machbar. und natürlich muss man einen guten epgfilter einrichten.
2. das handling vom sectionsd müßte verändert werden. in der aktuellen version werden trotz epg speicherpfad beim starten scheinbar erstmal epg daten vom sat/kabel gesammelt - erst anschließend, wenn sich der sectionsd eigentlich schlafen legt - werden die daten aus dem epg speicherpfad ausgelesen.
3. wenn es im var gespeichert sein soll muss man auf plugins verzichten
mit dem sectionsdcontrol kann man ja ein bissl herumspielen. epg daten über einige transponder sammeln und mit --wepg /pfad/ abspeichern.
bei einer einstellung von 4 tagen im vorraus, 6 stunden langtext, max 6000 events und 3h verwerfen kommen etwa 1.5MB gespeicherte XML Daten zusammen. Das Schreiben der Daten läßt sich mit mini modifikationen auf 3-5 sekunden reduzieren (komplett ohne extendedtext). sectionsdcontrol --fremem und anschließendes --repg /pfad/ dauert aber dann bis zu 120 sekunden, bis überall ein epg in der übersicht auftaucht. ich habe mal mit inserteventsfromfile herumgespielt, bin aber nicht wirklich erfolgreich gewesen. auch eine sehr hohe priorität des readepg threads hat kaum etwas gebracht.
ich denke, wir sollten warten, bis die testecke sectionsd goes table abgeschlossen ist. wenn viele doppelte events aus der datenmenge verschwinden, ist sicherlich auch bei read/write epg noch eine möglichkeit, da was zu verbessern.
aber im var speichern .... nunja, ohne tuxtxt, tuxmail oder tuxcom könnte es vlt für ein ganz kleines epg funktionieren.
innu
