Sectionsd: Save EPG as Raw File

[palace]

Mit der Option EPG Speichern = ein dauert das Speichern / Laden nun doch recht lange...
Ich wünsche mir die Möglichkeit - für die, die -xml nicht benötigen - das EPG grad Stur RAW in ein File zu schreiben und zu laden....

Chris.

[usul1]

Ich wünsche mir die Möglichkeit - für die, die -xml nicht benötigen - das EPG grad Stur RAW in ein File zu schreiben und zu laden....

Wofür könnte das XML denn überhaupt benötigt werden?

Ansonsten: Ja, bitte. Wenns schneller geht und sich da jemand rantraut wäre RAW toll.

Und dann noch einen Commandline Switch für den Sectionsd zum laden/speichern und man würde die EPG Infos auch nicht mehr bei der Aufnahme verlieren (Ich kille den sectionsd im Record.start da sonst die Aufnahmen nicht vernünftig gehen).

cu
usul

[mb405]

also das kommando in der sectionsd.cpp zum epg laden ist

readSIfromXML

ich hab den aufruf in der neutrino.cpp gefunden

g_Sectionsd->readSIfromXML(g_settings.epg_dir);

also müsste in die sectionsd.cpp sowas in der art rein.

Code: Alles auswählen

else if (!strcmp(argv[i], "-nu")) {
	update_eit = false;
	printf("[sectionsd] EIT update disabled\n");
	}
else if (!strcmp(argv[i], "-repg")) {
	//hier der aufruf für das einlesen
	printf("[sectionsd] read epg data\n");
	}

vielleicht geben Houdini und Nirvana einen tip ab, wie es zu realisieren wäre.

[Nirvana]

Na, die Sache mit dem Raw hatten wir ja schon. Irgendeine Art von Struktur muss eine Datei schon haben (genau wie der Speicher). Die gewählte Form ist xml. Und das ist auch richtig so.
Langsam wird es nur durch ineffiziente Programmierung.

[mb405]

@Nirvana
kannst du meinen vorigen post den code mal ansehen, wie die sectionsd per befehlszeilenparameter den epg neu einliest ?? wegen aufnahmen und killen des daemons dabei.
Dank

[PauleFoul]

Na, die Sache mit dem Raw hatten wir ja schon. Irgendeine Art von Struktur muss eine Datei schon haben (genau wie der Speicher). Die gewählte Form ist xml. Und das ist auch richtig so.
Langsam wird es nur durch ineffiziente Programmierung.

Wobei mir immer noch nicht klar ist, warum sich die Formate unterscheiden
müssen...



Gruß
____Paule

[Günther]

Na, die Sache mit dem Raw hatten wir ja schon. Irgendeine Art von Struktur muss eine Datei schon haben (genau wie der Speicher). Die gewählte Form ist xml. Und das ist auch richtig so.
Langsam wird es nur durch ineffiziente Programmierung.

Ich denke schon auch, das xml recht ineffektiv ist. Ist aber auch nicht wirklich für embedded devices entwickelt worden . Ein raw-Format 'verbraucht' sicherlich 2-3 mal weniger Speicher und bei einem gut abgestimmten Format (welches möglichst ähnlich zu dem Format ist,welches in der SW benutzt wird) ist dann auch relativ wenig Rechenaufwand beim Einlesen notwendig.
Dafür ist raw entwicklungsaufwendiger, fehleranfälliger und weniger gut wartbar. Mit einem Standard ist man (wenn man es sich Speicher- und Prozessortechnisch leisten kann) immer besser bedient.
Günther

[usul1]

Dafür ist raw entwicklungsaufwendiger, fehleranfälliger und weniger gut wartbar. Mit einem Standard ist man (wenn man es sich Speicher- und Prozessortechnisch leisten kann) immer besser bedient.
Günther

Was für ein Standard?
Ich habe mal was geschrieben was das Sectionsd EPG XML erzeugt. Wäre ich nicht naiv davon ausgegangen das es XML ist hätte ich mir eine Menge Zeit sparen können. ;-)
Das was der Sectionsd zum EPG lesen/schreiben nutzt ist halt kein XML sondern ein propertäres Format was zufällig einer Form von XML entspricht (Nehmt mal andere Feldbegrenzer (') und schaut wie schnell der sectionsd beim einlesen abschmiert ;-).

XML ist ja schön und gut. Aber wenns nicht richtig implementiert wird soll man lieber die Finger davon lasen und lieber gleich irgenwas eigenes nehmen.

Also beim Sectionsd Speicherformat sehe ich absolut keine Vorteile darin dieses XML ähnliche Format zu nutzen.
Abgesehen davon das man es eh nicht sinnvoll weiterverarbeiten kann solange die Felder und Datentypen nirgens dokumentiert sind.
Denn ob ich mich durch den Quellcode wühle um zu schauen wie das XML aufgebaut ist oder um zu schauen wie das Binärformat aufgebaut ist, ist vollkommen egal.

Also wenn XML dann bitte richtig. Son halbgarer Mischmasch hilft auch nicht weiter.

cu
us'das wollte ich schon länger mal los werden ;-)'ul

[Nirvana]

Wie dem auch sei: Ich habe nur die Funktionen genutzt, die schon da waren. Und die schreiben die Daten nun einmal so. Und der XML-Parser ist auch nicht sectionsd spezifisch, sondern war schon immer so in Neutrino.
Was ich auf der anderen Seite komplett verurteile, ist z.B. das VDR Format. Das kann kein Mensch lesen.
VDR ist ein tolles Gerät, aber channels.conf und epg.data sind eine Zumutung.
Insofern finde ich es gut, wie es im Moment in Neutrino ist, was aber nicht heißen soll, dass es nicht verbessert werden kann. Nur leider nicht von mir.

[mb405]

also Nirvanas sache funktioniert perfekt. wieso da drin rumpatchen ?

[Nirvana]

Nö, perfekt ist anders. Es könnte schneller gehen, aber mir reicht es. Ihr wisst ja: kein Fortschritt ohne die Unzufriedenen.

[usul1]

Wie dem auch sei: Ich habe nur die Funktionen genutzt, die schon da waren. Und die schreiben die Daten nun einmal so. Und der XML-Parser ist auch nicht sectionsd spezifisch, sondern war schon immer so in Neutrino.

Ist schon klar. Das ganze war ja auch kein Vorwurf in Richtung "Du hast da irgendeinen Mist programmiert" sondern Kritik in Richtung "Im Ergebnis funktioniert da einiges nicht".
Wobei das "nicht funktionieren" eher subjektiv ist. Denn das was du eigentlich machen wolltest (EPG laden und speichern) funktioniert ja gut (Obs anderst schneller geht müsste ja noch bewiesen werden).

Allerdings funktionieren da einige Sachen nicht ideal wenn man diese EPG XML Dateien als Schnittstelle betrachtet.
Aber da du diese Sache offensichtlich nie als Schnittstelle gedacht hast stellt sich die Frage: Warum denn überhaupt XML?
Und darauf wollte ich eigentlich hinaus. Warum nimmt man XML wenn es eh nicht vorgesehen ist das andere Programm diese Daten weiterverarbeiten?

Was ich auf der anderen Seite komplett verurteile, ist z.B. das VDR Format. Das kann kein Mensch lesen.

Es mus auch kein Mensch lesen können ;-)

Aber ich denke jetzt wissen wir warum du dich für XML entschieden hast. Du magst anscheinend Plaintext Dateien. OK, jeder wie er mag.

also Nirvanas sache funktioniert perfekt. wieso da drin rumpatchen ?

Ich glaube hier wurde schon erwähnt was nicht funktioniert (Jedenfalls nach der persönlichen Meinung einiger Leute) ;-)

cu
usul

[Nirvana]

@usul1

Nee, ganz hast du mich noch nicht verstanden. Es war keine Entscheidung pro oder contra xml. Die Funktionen zum Schreiben der Daten waren einfach da und diese Faulheit irgendwas relativ gedankenlos zu benutzen kennt glaube ich jeder Programmierer.
Hauptsache es läuft erstmal.
Natürlich war es auch so gedacht, dass andere Programme dieses Interface nutzen. Nach VDR importiere ich ja auch schon ewig den EPG aus dem Internet.
Und zumindest die Programmierer (sind ja auch irgendwie Menschen) müssen die Datei lesen. Und da fand ich den Klartext schon hilfreich.

[usul1]

Nee, ganz hast du mich noch nicht verstanden. Es war keine Entscheidung pro oder contra xml. Die Funktionen zum Schreiben der Daten waren einfach da

Ach so, ich dachte du hast das schreiben/lesen erst eingebaut.
War das schreiben von vorherrein zum besssseren debuggen drin (Dann würde ich die Entscheidung für Plaintext natürlich verstehen)?

Natürlich war es auch so gedacht, dass andere Programme dieses Interface nutzen. Nach VDR importiere ich ja auch schon ewig den EPG aus dem Internet.

Aber du hast kein Interesse an wenigen klitzekleinen Änderungen am Sectionsd um auch in der DBOX EPG Daten aus dem Internet zu importieren?
Nicht das du dazu irgendwie verpflichtet bist. Aber wenn du es schon beim VDR tust wundert es mich das du es nicht auch bei der DBOX tun möchtest.

Weil prinzipiell ist es ja kein Problem dem Sectionsd auf diesem Wege weitere EPG Daten unterzuschieben (Prinzipiell funktioniert das ja jetzt schon bei Sendern die kein eigenes EPG haben). Das einzige woran es scheitert ist ja das sinnlose EPG Daten vom Transponder (Wie z.B. bei "NICK") die selbst geladenen überschreiben.

Ansonsten ist es ja simpel. Man nimmt die EPG Daten aus dem Internet und konvertiert die ins Sctionsd XML Format. Dann den Sectionsd so einstellen das die EPG Daten beim Start geladen werden und schon hat man die EPG Daten aus dem Internet im DBOX EPG.

cu
usul

[Nirvana]

Dann sprechen wir mal über die klitzekleinen Änderungen. Ist ja grad Weihnachten, da darf man sich was wünschen.
Ich kann mir nicht vorstellen, wie das funktionieren soll. Soll ich dem sectionsd das EPG-suchen vom Sat ganz abgewöhnen? Das wäre einfach. Aber was ist dann mit Sendern, für die ich keinen EPG im Internet finde? Irgendwie kann es das nicht sein, oder? Außer vielleicht als Anfang...
Oder man müsste einen selektiven EPG-Blocker schreiben nach ONID, TSID, SID, das wäre aber nicht so ganz klitzeklein als Änderung, vielleicht aber sowieso sinnvoll um den Speicher effizienter zu nutzen.
Meinungen?

[PauleFoul]

@ Nirvana

Da wir ja wie bereits erwähnt Weihnachten haben und Du einen Wunsch/
Person ausgegeben hast, möchte ich meinen auf diesem Wege gleich
mal los werden...

Zum Thema: "Platz sparen".
Kannst Du bitte eine Option einbauen, dass die Berschreibungen der
einzelnen Events/Sendungen nicht gleich mitgeladen werden, sondern
erst wenn man die entsprechende Seite aufruft. Auch wenn es dann
ein paar Sekunden dauert bis der Text erscheint, meine ich dass das
immer noch akzeptabel ist, einen Haufen Speicher spart und die
Stabilität erhöht.


Gruß & Frohes Fest
_______________Paule

[usul1]

Dann sprechen wir mal über die klitzekleinen Änderungen. Ist ja grad Weihnachten, da darf man sich was wünschen.

Nungut, "klitzekleine" natürlich aus Sicht des Nutzers der sich was wünscht. Irgenwie sind ja alle Wünsche von Nutzern immer mal eben schnell Programmiert und überhaupt kein Problem ;-)

Aber wünschen tue ich mir natürlich gerne was.

Ich kann mir nicht vorstellen, wie das funktionieren soll. Soll ich dem sectionsd das EPG-suchen vom Sat ganz abgewöhnen?

Ich weiß nicht genau wie der Sectionsd nun im Detail aufgebaut ist.

Aber im Prinzip stelle ich mir es so vor das für jeden Sender eine Liste (Also sowas wie eine Reihe von Pointern zu Speicherstellen indenen jeweils der Text (und die dazugehörigen Flags usw.) eines EPG Eintrages liegen) mit den EPG Daten im Speicher liegt.
Sammelt er nun die EPG Daten vom Transponder ein weiß er ja für welchen Sender diese sind (zwangsläufig) und sortiert es in die Liste ein die die EPG Daten für DIESEN Sender speichert.
Nun müsste man in jeder Liste nur ein Flag bereithalten was sagt "für diesen Sender keine EPG Daten sammeln".
Dann müsste der Sectionsd nur vor dem Abspeichern der neuen Daten in die Liste schauen ob das abspeichern für DIESE Liste (D.h. diesen Sender) überhaupt gewünscht ist. Wenn nicht lässt er es einfach.

Also vermutlich nur anstelle von:
---
NeuGesammelteEpgDatenImSpeicherAblegen;
---
ein:
---
If (Flag "EPG Daten von SI sammeln" in der EPG Liste des Senders für die wir gerade neue Daten gesammelt haben) = true then NeuGesammelteEpgDatenImSpeicherAblegen;
---

Das Flag wird natürlich beim einlesen der XML EPG Daten gesetzt. Dafür nimmt man nur ein neues Atribut im XML auf.
---
<dvbepg>
<service original_network_id="0020" transport_stream_id="0459" service_id="313a" overvrite_with_si="false">
---
Beim Einlesen wird dann bei 'overvrite_with_si="false"' das Flag in der Variablen die das EPG für DIESEN Sender im Speicher hält gesetzt. Default für dieses Flag ist dann natürlich "true". Dann werden Sender für die es beim Laden kein XML File gab (oder aus irgendeinen Grund das Flag "true" ist) automatisch wie bissher behandelt.

Das heist es bleibt alles wie es ist. Nur das es möglich ist für bestimmte Listen (Die schon beim Start durchs EPG einlesen gefüllt wurden) das ändern des Inhaltes zu unterbinden.

(Ich hoffe ich habe es geschaft das einigermassen verständlich rüberzubringen)


- Dann natürlich noch eine Funktion die es erlaubt die EPG Daten nur zu lesen aber beim beenden nicht zu speichern (Das mus AFAIK aber in Neutrino geändert werden. Und zu vermeiden das Neutrino beim beenden die EPG speichern Funktion vom Sectionsd aufruft sollte wohl auch nicht sooo schwierig sein). Denn irgenwie bleibt das EPG Speichern bei mir meistens hängen (Ich speichere auf ein per FTPFS gemontetes Verzeichnis).

- Ferner wäre es schön dem sectionsd abzugewöhnen abzustürzen wenn die zu ladenen EPG Daten weiter in der Zukunft liegen als "jetzt + maximale Speicherzeit".

- Mit den Eigenheiten des Sectionsd XML Formates kann man leben. Wenn man einmal rausgefunden hat wie es funktioniert kann man sie ja so schreiben wie der Sectionsd (bzw. der genutzte XML Parser) es gerne hätte. Also hier gibt es kein wirkliches Problem.

Oder man müsste einen selektiven EPG-Blocker schreiben nach ONID, TSID, SID, das wäre aber nicht so ganz klitzeklein als Änderung, vielleicht aber sowieso sinnvoll um den Speicher effizienter zu nutzen.
Meinungen?

Das wären ja eh unabhängig davon meine (und vermutlich fänden das alle praktisch) weiteren Wünsche für den Sectionsd:

1. EPG ummappen. Wenn man dem Sectionsd sagen könnte das es z.B. für RTL Schweiz den EPG für RTL Deutschland liefern könnte.

2. Wie du schon sagtest EPGs rausfiltern. Ich habe kein Premiere Abo, also brauche ich das Premiere EPG nicht im Speicher.
Aber das wird vermutlich nicht so einfach umzusetzen sein. Denn im Idealfall sind das (Von diesem Sender EPG Sammeln) Flags in der Senderliste, so das man (Wie bei den Technisatreceivern fürs SFI) in der Bougetverwaltung das EPG für einzelne Sender anwählen/abwählen kann/muss.

Ferner wäre es dann auch schön trotzdem das EPG eines Senders, für den man das EPG nicht gewählt hat, zu sehen wenn man auf ihn umschaltet (Z.B. wenn man das Premiere EPG nicht speichern lässt aber ab und zu trotzdem mal auf die Premiere Kanäle schalten kann um zu sehen was man nun schauen könnte wenn man ein Abo hätte).


Aber ich vermute das sind dann nicht mehr so ganz "klitzekleine" Änderungen ;-)

cu
usul

[PauleFoul]

@ usul1

Das war jetzt aber mehr als ein Wunsch...

[usul1]

@ usul1

Das war jetzt aber mehr als ein Wunsch...

Teil zwei war kein konkreter Wunsch (Als Antwort auf seine Frage nach einen Wunsch) sondern nur eine Reaktion auf seine Frage nach Meinungen. Mann wills mit den Wünschen ja nicht gleich übertreiben

cu
usul

[Nirvana]

Weil sonst offtopic mach' ich mit dem Filter mal hier weiter:
http://forum.tuxbox-cvs.sourceforge.net ... p?p=319450