EPG schneller speichern und laden

[Kermit21]

Hallo,

habe mal eine aktuelle Version ausgetestet: Das Speichern des EPGs beim runterfahren und laden nach dem Hochfahren dauert immer noch Ewigkeiten. Kann man das nicht mal fixen, dass es fix geht? Es kann doch nicht sein, dass die paar Daten so lange brauchen? Kann man das ganze EPG nicht während des Betriebs in einer Art (komprimierte?) Datenbankdatei im ramdisk (/tmp) ablegen, so dass immer darauf zugegriffen wird? Dann müsste man beim runterfahren die Datei nur automatisch auf die HDD oder Netzlaufwerk kopieren und beim hochfahren zurück in die Ramdisk?

[rhabarber1848]

Einen funktionierenden Patch checke ich gerne ins CVS ein, hast Du schon was parat?

[seife]

Ausserdem hat mich noch niemand so richtig von der Nützlichkeit des features überzeugen können (ok, speichern evtl. schon, als "export" der EPG Daten, aber wozu man die wieder in den sectionsd laden wollen würde, hat noch niemand plausibel erklären können).

[Houdini]

und 5 - 20 MB Daten von einer 66 MHz CPU in ein xml Format konvertieren zu lassen und abzuspeichern dauert halt auch seine Zeit...

[Kermit21]

Ich glaube, ihr versteht mein Problem nicht: Wieso müssen die Daten überhaupt in eine xml-Datei konvertiert werden? Die Daten liegen während des Betriebes ja sowieso in irgendeiner Form im Arbeitsspeicher! Kann man sie in dieser Form (ohne zu konvertieren!) nicht einfach beim Runterfahren auf die Platte schreiben und beim Hochfahren wieder laden?
Selbst 20MB sind doch in wenigen Sekunden geschrieben/gelesen?

Ich weiß auch nicht, was es an der Nützlichkeit nicht zu verstehen gibt? Ich fahre zum Stromsparen meine Box immer in den Deep-Standby. Und dann gehen alle EPG-Daten verloren. Wenn ich wieder anschalte, muss ich erst mal mühsam die Transponder durchzappen und warten, bis ich die EPG-Daten habe.

[MTM]

Hallo,
sie liegen im Speicher ja als Pointer-Struktur oder sowas in der Art vor, wie willst du das einfach so abspeichern? Deshalb müssen sie erstmal in eine Form aufbereitet werden, daß sie sich abspeichern lassen.

MfG,
MTM.

[Kermit21]

Ich bin zwar kein Programmierer. Aber ist es denn so schwer, den Speicherinhalt (auf den die Pointer zeigen) direkt binär in eine Datei zu schreiben beim Runterfahren und beim Hochfahren wieder auszulesen, bzw. besser direkt diese Datei zu nutzen?
BTW: Wenn es nur einfache Pointer sind, bedeutet das etwa, dass die EPG-Daten unkomprimiert im Arbeitsspeicher liegen? Ist das nicht eine immense Speicherverschwendung?

Darum auch meine Ursprungsidee die Daten direkt in eine Datei im /tmp-Verzeichniss (zumindest mit gzip komprimiert) abzulegen und bei Bedarf (Bouquetaufruf mit OK-Taste) direkt von dort zu lesen. Da /tmp ja eh im Arbeitsspeicher liegt, sollte das zeitlich keinen so großen Unterschied machen. Und eine einfache gzip-Komprimierung unterstüzen ja sogar schon die Konsolen-Tools der busybox (gzip, gunzip, zcat), da sollte es Programmiertechnisch doch auch nicht so schwer sein sowas zu nutzen?

Aber wie gesagt, ich bin nur ein Laie und lasse mich gerne eines besseren belehren.

[dbt]

BTW: Wenn es nur einfache Pointer sind, bedeutet das etwa, dass die EPG-Daten unkomprimiert im Arbeitsspeicher liegen? Ist das nicht eine immense Speicherverschwendung?

Darum auch meine Ursprungsidee die Daten direkt in eine Datei im /tmp-Verzeichniss (zumindest mit gzip komprimiert) abzulegen und bei Bedarf (Bouquetaufruf mit OK-Taste) direkt von dort zu lesen. Da /tmp ja eh im Arbeitsspeicher liegt, sollte das zeitlich keinen so großen Unterschied machen. Und eine einfache gzip-Komprimierung unterstüzen ja sogar schon die Konsolen-Tools der busybox (gzip, gunzip, zcat), da sollte es Programmiertechnisch doch auch nicht so schwer sein sowas zu nutzen?

Aber wie gesagt, ich bin nur ein Laie und lasse mich gerne eines besseren belehren.

Das wäre aber doppelt gemoppelt, wenn das im /tmp und Arbeitsspeicher liegt, also eine noch größere Verschwendung und wie Houdini schon gesagt hat, eine 66Mhz Maschine hat so schon genug um die Ohren

[Kermit21]

Das wäre aber doppelt gemoppelt, wenn das im /tmp und Arbeitsspeicher liegt, also eine noch größere Verschwendung und wie Houdini schon gesagt hat, eine 66Mhz Maschine hat so schon genug um die Ohren

/tmp ist der Arbeitsspeicher. Die sollen nur in /tmp ausgelagert werden und _immer_, bei jeder EPG-Verarbeitung, von dort gelesen und geschrieben werden.
Und selbst mit 66MHz sollte eine einfache gzip-Komprimierung doch kein Problem darstellen? Beim normalen Schauen habe ich zumindest 80-90% Idle. Beim Aufruf des aktuellen Bouquets (OK-Taste) ändert sich nicht viel. Lediglich wenn ich wie ein irrer permanent die Bouquets wechsel, sehe ich wie der Idle-Prozess in den Keller geht.

[dbt]

/tmp ist der Arbeitsspeicher.

das meinte ich ja. warum das 2x darein quetschen.
Mag sein, das 66Mhz ausreichend sind, aber es wird schon seine Gründe gehabt haben, warum das so ist, wie es jetzt ist.
Um's genauer nachvollziehen zu können, müsste man es schon testen, hast du dafür einen Patch?

Edit:
Und in punkto packen/entpacken habe ich schon mal mit anderen Daten auf der dbox versucht einiges zu machen und das mag zwar gehen, ist aber je nach Packer und ob man aus oder einpackt unterschiedlich und die fressen bekanntlich auch jede Menge Ram. Ich habs darauf hin zu den Akten gelegt. Am meisten ging die Box baim Packen in die Knie. Mit den lzma-utils war die box extrem unhandlich und je mehr Kompression man nimmt umso schlimmer wirds, vom verbratenen Ram mal ganz zu schweigen.

[PauleFoul]

Hatte man nicht mal drüber gesprochen bei runterfahren quasi ein Speicherabbild auf Festplatte zu schreiben und dies beim booten wieder zu laden?

Dann könnte man sich in der Tat die lange Umwandlung der EPG Daten sparen...

[seife]

Was du meinst ist "suspend to disk" und das macht für die dbox jetzt nicht wirklich sinn

[PauleFoul]

Was du meinst ist "suspend to disk" und das macht für die dbox jetzt nicht wirklich sinn

Was zu beweisen wäre...

Ich finde es nicht so abwägig die EPG Daten quasi 1:1 vom Speicher auf Platte zu schreiben, oder liege ich da falsch?

[seife]

Ich finde es abwegig, leicht verderbliche Daten (wie EPG) überhaupt irgendwohin zu schreiben

[PauleFoul]

Ich finde es abwegig, leicht verderbliche Daten (wie EPG) überhaupt irgendwohin zu schreiben

Naja, wenn man mal für mehrere Sender fast eine Woche eingelesen hat und das funktioniert auf der dbox ja so perfekt
wie auf wenigen Receivern, finde ich das es schon ein Feature wäre diese für den nächsten Tag "aufzuheben" um nach
dem Booten gleich eine komplette Übersicht zu haben.
Aber eben nur wenn sich das runter und vorallem das hochfahren dadurch nicht um Minuten verlängert...

[Kermit21]

/tmp ist der Arbeitsspeicher.

das meinte ich ja. warum das 2x darein quetschen.
Mag sein, das 66Mhz ausreichend sind, aber es wird schon seine Gründe gehabt haben, warum das so ist, wie es jetzt ist.
Um's genauer nachvollziehen zu können, müsste man es schon testen, hast du dafür einen Patch?

Ich bin kein Programmierer (wenn mal mal einfache Scriptsprachen unberücksichtigt lässt). Dieses Unterforum heißt nebenbei bemerkt auch "Feature Requests" und nicht "Feature deliveries"

Und wieso 2x darein quetschen? EPG-Daten in einer komprimierten Datei in /tmp speichern. Sonst haben die Daten nirgendwo unkomprimiert im Arbeitsspeicher zu liegen! Bei bedarf, muss man sie halt immer aus der Datei holen. Aber nicht immer alle:
Nur die EPG-Titel der aktuellen (und ggf. der nächsten) Sendungen jedes Kanals unkomprimiert im Speicher behalten für die schnelle Übersicht (damit man nicht bei jedem aufrufen der Kanalliste Teile aus der /tmp-Datei holen muss und deshalb ggf. mit Wartezeiten auf die Kanalliste warten muss). Zusätzlich vielleicht noch alle EPG-Daten des aktuellen Senders unkomprimiert im Speicher behalten, bzw. beim Umschalten nachladen. Die unkomprimierten Daten des vorherigen Senders (vor dem Umschalten) können dann wieder aus dem Arbeitsspeicher gelöscht werden.
Ich kann mir durchaus vorstellen, dass das deutlich weniger Arbeitsspeicher belegt!
Jene wenige "doppelte" unkomprimierten Daten + alle Daten komprimiert sollten doch deutlich kleiner sein als wenn alle Daten unkomprimiert die ganze Zeit im Arbeitsspeicher Platz belegen, wovon die meisten eh nie genutzt werden.

Edit:
Und in punkto packen/entpacken habe ich schon mal mit anderen Daten auf der dbox versucht einiges zu machen und das mag zwar gehen, ist aber je nach Packer und ob man aus oder einpackt unterschiedlich und die fressen bekanntlich auch jede Menge Ram. Ich habs darauf hin zu den Akten gelegt. Am meisten ging die Box baim Packen in die Knie. Mit den lzma-utils war die box extrem unhandlich und je mehr Kompression man nimmt umso schlimmer wirds, vom verbratenen Ram mal ganz zu schweigen.

Es reicht doch ein schlechter, schneller Kompressionsgrad. Die EPG-Daten sind doch nur Text. Die lassen sich also sehr gut packen. Wenn die Daten bisher eh komplett unkomprimiert im Arbeitsspeicher lagen, dann kommt es auf einen hohen Kompressionsgrad erst mal nicht an!
Zur Geschwindigkeit: Dass das Packen länger dauert ist mir klar. Wichtig ist aber nur ein schnelles Entpacken! Natürlich muss das Komprimierungsverfahren auch so gestrickt sein, dass man nicht immer das komplette Archiv packen/entpacken muss, um Teildaten herauszuholen oder um das Archiv mit zusätzlichen Daten zu erweitern! Mit Komprimierungsverfahren kenne ich mich aber auch nicht so aus. Aber es gibt ja sogar komprimierte Dateisysteme, die auch schreibbar sind (wie z.B. jffs2*g*). Kann man eine Ramdisk nicht einfach so ein Dateisystem verpassen? Bzw. man kann doch unter Linux sogar auch Dateien als Loop-Device mounten. Und jffs2 kann der Kernel ja schon...
Aber noch mal zurück zur Geschwindigkeit: Wenn ich einen Sender schaue, dann sind doch wohl genügend Ressourcen frei, um im Hintergrund die EPG-Daten anderer Sender, die sectionsd am sammeln ist, gleich zu komprimieren (wobei die Titel der laufenden und nächsten Sendung auch unkomprimiert behalten werden).
Jetzt schalte ich um. Dabei sollte es zu keinen Geschwindigkeitseinbußen kommen. Im am unteren Bildrand erscheinenden OSD steht auch direkt der aktuelle und nächste Titel (weil die ja nach wie vor sofort unkomprimiert im Speicher zur Verfügung sind). Allso alles wie gehabt. Während der Sender nun läuft, schmeißt sectionsd die unkomprimierten EPG-Daten des vorherigen Senders weg (bis auf Titel der aktuellen und nächsten Sendung) und lädt sich aus dem komprimierten Archiv die EPG-Daten des aktuellen Senders nach.

Anderes Szenario, wo es zu Engpässen kommen könnte: Ich rufe die Kanalliste auf, scrolle auf einen anderen Kanal und will mir das EPG direkt anzeigen lassen _ohne_ auf den Kanal umzuschalten (=rote Taste in der Kanalliste). Nun muss sectionsd halt nachladen. Hier kann es dann zu einer kleinen Verzögerung kommen. Allerdings kann ich mir nicht vorstellen, dass das Entpacken eines so kleinen Teiles von einem Archiv, dass eh schon im Arbeitsspeicher liegt, so lange dauert, dass man die Zeit überhaupt merkt? Wenn ich z.B. zcat im Terminal aufrufe, erhalte ich ja auch sofort die Daten einer komprimierten Textdatei ohne spürbare Verzögerung gegenüber einem cat einer unkomprimierten Textdatei.


Zugegeben: Sowas zu Programmieren ist sicher nicht ganz einfach. Aber da der Source der Coolstream nun ja öffentlich ist, ist die DBox-HW vermutlich eh bald obsolet. Bei der Coolstream soll es ja angeblich keine sectionsd mehr geben. Vielleicht ist dort dann einfacher EPG-Daten zu speichern. Mal sehen was die Zukunft bringt...

[seife]

Den "sectionsd" gibt bei neutrino-hd (ich nenn es mal so) immer noch. Es ist nur kein eigener Prozess.

Das mit der Komprimierung halte ich für nicht mit vertretbarem Aufwand machbar, es ist wesentlich weniger aufwändig, einfach 64MB in die Box zu löten.

Evtl. könnte man auch mit handgestrickten Datenstrukturen anstelle von C++-STL den Speicherbedarf optimieren, aber das wäre halt sehr viel Arbeit und man würde evtl. den Code um einiges unlesbarer machen.

[Houdini]

Was mir so im Kopf rumschwebt ist eine Anwendung auf einem Server, die den EPG entgegennimmt und dann auf die Box(en) zurückliefert.
Die Daten können in einer Datenbank auf dem Server gespeichert werden. (mysql?)
Per SQL Abfrage kann die Box den EPG von einem Sender/einer Zeit usw. vom Server abholen.
Sectionsd würde die Daten zum Server schicken, und neutrino per sectionsdclient mit dem Server kommunizieren.

[PauleFoul]

Warum es im Kern geht ist doch den EPG im Speicher in einem Format zu halten (einfachst), das
beim Beenden bzw. Starten 1:1 auf Platte geschrieben bzw gelesen werden kann.
Die jetzige Umwandlung in XML dauert einfach zu lange. So macht es keinen Spaß...


Gruß