sectionsd & Cachestrategie

[Nirvana]

Was haltet ihr da für vernünftig?

Die Ausgangssituation ist klar:
Wir haben mehr Informationen als wir (Ram-) Speicher haben. Im Moment verzichten wir auf die Informationen, die am weitesten in der Zukunft liegen. Ist das die beste Strategie?

Den meisten Speicher belegen die ausführlichen Beschreibungen. Könnte man nicht extended events nur für 24h in die Zukunft speichern und ansonsten nur Zeit und Name. Wäre das besser? Hat da schon mal jemand experimentiert? U.U. findet ja jemand die Zeit, mal die gesicherten EPG-XML-Dateien zu analysieren.

Oder man könnte grundsätzlich zulassen, dass der aktuelle Sender alle seine Events speichern darf.
Oder man könnte auch Infos auf die FP auslagern. Was wäre denn da ein guter Algorithmus? Eventuell würde es dann ein paar Sekunden dauern, bis die Programmvorschau steht.

Oder man könnte die Infos natürlich komprimieren, aber das wäre sehr aufwändig.

Hat jemand vielleicht eine zündende Idee, wie man mit dem Problem umgehen könnte?

[usul1]

Was haltet ihr da für vernünftig?

Den meisten Speicher belegen die ausführlichen Beschreibungen. Könnte man nicht extended events nur für 24h in die Zukunft speichern und ansonsten nur Zeit und Name. Wäre das besser?

Dagegen. Gibt eh schon zu wenig EPG Daten. Da braucht man nicht auch noch auf die Beschreibung verzichten wenn dieses glücklicherweise schon mal da ist.

Oder man könnte auch Infos auf die FP auslagern.

Gibt doch gerade das "SD Karte an den Modemport" Posting. Das wäre doch eine gute Sache zum Auslagern des EPG (auch über den AUS Zustand hinweg).

Hat jemand vielleicht eine zündende Idee, wie man mit dem Problem umgehen könnte?

Ein "EPG Flag" zu den einzelnen Sendern in der services.xml. Und nur das EPG dieser Sender wird gespeichert (SFI macht das doch auch so).


BTW: Warum nicht kompremieren?
Es würde ja schon etwas bringen nur die Texte der erweiterten Beschreibungen einzeln zu kompremieren.
Man könnte dafür ja was schnelles leicht kompremierendes nehmen. Z.b. gabs mal den Algo für das AportisDoc Textformat *) welches auf PalmOS PDAs genutzt wurde als dort Geschwindigkeit und Speicher noch knapp waren. Bringt IIRC nur ein Kompression auf ca. 60% (hängt natürlich vom Text ab) aber bevor die DBOX sich langweilt und nichts zu tun hat kann sie auch kompremieren.

cu
usul

*) Ist speziell für ASCII Texte gedacht. Sinn ist es Leeerzeichen+Zeichen durch 1 Zeichen zu ersetzen und Wiederholungen von Buchstabenfolgen duch Pointer auf die schon vorhandene zu ersetzen.
Irgendwo sollte es das auch in C und unter GPL geben.
Für Experimente gibts das in Python (doc_compress.py) im Plucker parser (http://www.plkr.org).
Evtl. bringt das ja Vorteile gegenüber ZLIB.

Edit: OK gerade mal einwenig gespielt. Die Beschreibungen einzeln werden auf 70%-85% kompremiert. Je Länger die Texte desto besser. Also nicht so toll (hätt ja sein können ).
BTW: ZLib ist auch nicht besser.

Wer mal selber spielen will:

Code: Alles auswählen

#!/usr/bin/env python

import getopt, sys, string, doc_compress, zlib

if len(sys.argv) != 2:
  print "Usage: %s <textfile>" % sys.argv[0]
  print "  Example: %s test.txt" % sys.argv[0]
else:
  sys.stderr.write("Reading File: %s\n" % sys.argv[1])
  f = open (sys.argv[1], "r")
  text = string.join (f.readlines (), "")
  tc = doc_compress.compress(text)
  sys.stderr.write("Doc: Input Size %d; Compressed Size %d; Ratio %d%%\n" % (len(text),len(tc),(len(tc)*100/len(text))))
  tc = zlib.compress(text)
  sys.stderr.write("ZLib: Input Size %d; Compressed Size %d; Ratio %d%%\n" % (len(text),len(tc),(len(tc)*100/len(text))))
  f.close ()

[Nirvana]

Ein "EPG Flag" zu den einzelnen Sendern in der services.xml. Und nur das EPG dieser Sender wird gespeichert (SFI macht das doch auch so).

Wobei da wieder die Trennung sectionsd/zapit nervt. Da würde dann zapit die services.xml parsen um die Sendernamen zu erhalten und sectionsd würde das Flag auslesen. Das verzögert zumindest das Booten der Box...

[usul1]

Ein "EPG Flag" zu den einzelnen Sendern in der services.xml. Und nur das EPG dieser Sender wird gespeichert (SFI macht das doch auch so).

Wobei da wieder die Trennung sectionsd/zapit nervt. Da würde dann zapit die services.xml parsen um die Sendernamen zu erhalten und sectionsd würde das Flag auslesen. Das verzögert zumindest das Booten der Box...

War nur ne Idee. Dafür das das Softwaredesign da nicht mitmacht kann ich nichts ;-)

Kann Sectionsd Zapit nicht einfach bei Bedarf fragen ob dieses oder jener Sender das EPG Flag hat?

cu
usul

[FaselMan]

-

[FaselMan]

-

[FaselMan]

-

[petb]

Hallo,

eine Idee wäre:
Titel im Ram als Index und den (kompletten, jemals gelesenen) Inhalt auf einem Share.
Für alle Boxen im Netz, gespeichert wird immer alles, was vom Sender kommt während die Box selbst, nach dem Start oder nach Aufforderung dann anhand der vom Sender gekommenen Infos die "quasi" Datenbank durchliest und den Index erstellt.)

Das Optimum wäre:
sectionsd/zapit, wie auch immer füllen nur die Datenbank.
Die EPG Infos die angezeigt werden etc., werden dann nicht mehr vom sectionsd verarbeitet sondern durch eine neue Routine aus der Datenbank gelesen.

Aber das denke ich wird wohl eine zu große baustelle sein.


Alternativ für Leute ohne Share:
Titel als Index im Ram und Inhalt bei Bedarf, eben mit Zeitverzögerung aus dem aktuellen Sat-Datenstrom rausgesucht und dann angezeigt.
Dazu alternativ, wenn das jemand nicht möchte die Reduzierung auf x tage
ODER
Alles im Ram für bsp. 5 tage und sobald der 6te Tag angewählt wird, werden die ersten 5 aus dem Ram geworfen und dann die nächsten 5 gecacht usw.

Da ich nicht genau weis wie die genaue Verwaltung des Datenstroms des EPG, etc. von statten geht ist es nicht leicht gedanklich weiter geführte Ideen einzubringen.

Bye
PetB

[det-box]

Hi,
ich bin dafür die vollständige Senderbeschreibung nur für 24 Stunden zu halten und dafür mehr Tage die Titel speichern. dadurch kann man evtl wieder
5 Tage vorher Aufnahme-Timer eingeben.



Det

[usul1]

sectionsd/zapit, wie auch immer füllen nur die Datenbank.
Die EPG Infos die angezeigt werden etc., werden dann nicht mehr vom sectionsd verarbeitet sondern durch eine neue Routine aus der Datenbank gelesen.

Aber das denke ich wird wohl eine zu große baustelle sein.

Wenn wir schon träumen:
<traummodus>Eine Datenbank die per einfacher Schnittstelle von Programmen gefüllt/ausgelesen werden kann.
Sectiond wäre dann nur ein Programm was sie füllt. Andere (z.B. NextViewEPG auf dem PC) könnten sie unabhänig davon auch füllen.

Die Datenbank dann optional auf den Share (oder die SD Karte in der Box (wenn das klappt was gerade in einem anderen Thread gemacht wird)) so das es nicht verloren geht wenn die Box ausgeschaltet wird.</traummodus>

cu
usul

[petb]

Je mehr ich nachdenke, desto eher scheint mir für alle eine gute Lösung:

Titel/Zeit recht lange zu cachen und die Beschreibungen variabel vorzulesen bzw. rückwärts zu lesen.

So wie die ersten Videotext Sachen auf dem TV waren.

Da war es so das immer eine Seit rückwarts und 2 vorwärts im Speicher waren.

Also für die Box bezogen......
Vom aktuell im Auswahlfenster selektierten Zeitpunkt wird immer 6 Stunden rückwärts (frühere Zeitpunkte) und 12 Stunden vorwärts (neuere zeitpunkte) die weitergehenden Infos gespeichert und bei Bedarf nachgeführt.

So wäre für die Timerprogrammierung der Titel immer da und wer mehr Infos haben will muss eben etwas warten bis der teil nachgeholt wird bzw nachgeführt wird wenn man blättert.

Wie lange dauert es denn bis sich der Datenstrom wiederholt ?
Das wäre ja dann die maximale Wartezeit, wenn der EPG-Event gerade dabei war und nicht angezeigt wurde, bis er wieder gesendet wird ?

Bye
PetB
Bye
PetB

[usul1]

Nur so aus Neugier: Wieviel Speicher braucht das EPG denn jetzt so?
Und wieviel hat man denn so üblicherweise dafür da?

Wieso ist das denn jetzt aufeinmal ein Problem. Bissher ging es doch auch mit Beschreibungen für mehere Tage?
(Obwohl der Teletext Cached ja jetzt auch. Liegt das evtl. daran')

cu
usul

[kroki]

Hi,

als erstes würde ich mal nur EPG-Daten speichern, für Sender die auch in der services.xml vorhanden sind. Wenn ich da nur an die ARD-Transponder denke, würden sich die Daten schon stark dezimieren (Ich denke da an die ganzen doppelten Regionalprogramme usw.).
Zweitens wuerde ich den EPG für die Radioprogramme rausnehmen.....

Gruß Kroki

[usul1]

als erstes würde ich mal nur EPG-Daten speichern, für Sender die auch in der services.xml vorhanden sind.

Sind nicht ALLE Sender in der services.xml?

Zweitens wuerde ich den EPG für die Radioprogramme rausnehmen.....

Ob das den Leuten gefällt die auch Radio hören?

cu
usul

[FaselMan]

-

[Nirvana]

@det
Das ist eben auch meine Meinung. War ja nicht schwer zu raten. Lieber eine längere Vorschau und dafür auf ein paar ausführliche Infos verzichten. Aber klar, es gibt eben auch andere Meinungen. Allen wird es keiner recht machen.

@petb
Schön wärs schon, aber Verwaltungsaufwand. Naja, man kann ja wenigstens schon die XML Dateien importieren.

@kroki
Sectionsd weiß nicht, welche Sender in der services.xml sind. Er weiß auch nicht, ob es ein Radioevent oder Fernsehevent ist. -> Trennung sectionsd/zapit sucks.

@usul
Probleme treten auf, seit mehr Sender EPG haben und die ARD einen Radio TP mit 90 Sendern und 1 Woche Vorschau in Betrieb genommen hat.
DVB konform wäre eine Lösung mit dem EPG-Flag. Es wird ja auch im SDT signalisiert, ob ein Sender EPG hatz oder nicht. Von daher finde ich das Konzept nicht schlecht.

[usul1]

Schön wärs schon, aber Verwaltungsaufwand. Naja, man kann ja wenigstens schon die XML Dateien importieren.

Man kann EPG Daten per XML importieren?

Probleme treten auf, seit mehr Sender EPG haben und die ARD einen Radio TP mit 90 Sendern und 1 Woche Vorschau in Betrieb genommen hat.

Ach so. Habe ich so garnicht wargenommen. Da macht der Flag Vorschlag wohl wirklich Sinn. Ich habe ja z.B. auch immer das Premiere EPG was ich mangels Abo garnicht nutze. Da werde ich dann wohl auch ne menge überflüssiges ARD EPG haben wenn ich mal kurz auf den dokukanel gehe.

BTW: Zum EPG Flag hätte ich noch ne Idee die ich einfach mal in den Raum stellen möchte.
Die EPG Daten der Sender mit dem EPG Flag landen im permanenten EPG Cache.
Befindet man sich auf einem Sender ohne EPG Flag werden die EPG Daten dieses Senders (aller Sender dieses Providers) trotzdem gesammelt und landen im temporären EPG Chache der wieder gelöscht wird wenn man den Transponder verlässt.
So könnte man z.B. das Premiere EPG nicht sammeln lassen. Aber man könnte trotzdem mal auf einen Premiere Sender schalten und schauen was man dort sehen könnte hätte man ein Abo (Tue ich manchmal wenn nichts im TV kommt um zu sehen ob ein Abbo evtl. lohnen würde).
Genauso könnte man mal bei neuen Sendern reinschauen und entscheiden ob es sich lohnt dort das EPG Flag zu setzen.
Wie gesagt nur eine Idee. Auch das würde wahrscheinlich wieder größeren Aufwand erfordern.


Was denkst du jetzt eigenlich zum Auslagern der Daten in Dateien (oder auch nur zu Machbarkeit/dem Aufwand. Unabhängig davon ob du tatsächlich Lust hast sowas zu implementieren)?
Es sicht ja so aus als ob es in kürze Möglich ist einfach ne SD Karte in die Box zu stecken.
Da bieten sich doch tolle Möglichkeiten (unbegrenzt EPG Speicherplatz. Sofort EPG wenn man die Box anschaltet).

cu
usul

[Nirvana]

Man kann EPG Daten per XML importieren?

Ja, ist aber noch nicht im CVS. Das diff und die Diskussion findet hier statt:
http://forum.tuxbox-cvs.sourceforge.net ... &start=360

Scheint aber auch bei den anderen gut zu klappen. Bisher kamen jedenfalls noch keine Klagen.

[usul1]

Man kann EPG Daten per XML importieren?

Ja, ist aber noch nicht im CVS. Das diff und die Diskussion findet hier statt:
http://forum.tuxbox-cvs.sourceforge.net ... &start=360

Scheint aber auch bei den anderen gut zu klappen. Bisher kamen jedenfalls noch keine Klagen.

Klasse. Wenn das und der SD Kartensupport im CVS (und vorallem im YADI Image) sind hat man ja schon einen echten Mehrwert.

Dann würde es sich auch lohnen mal zu schauen ob man die gespeicherten XMLs mit den NextViewEPG XML mergen könnte (mus dann wohl doch mal wieder meine TV Karte einbauen und spielen).

cu
usul

[PauleFoul]

Warum kann man denn nicht einfach die RadioEPG-Daten Filtern.
Zumindestens im TV-Modus.
Die Information wäre ja schon in der Service.xml enthalten!

Ich denke die wenigsten Leute brauchen den RadioEPG...

Auch würde ich dafür pladieren endlich ein Menü für den Sectionsd
in Neutrino einzubauen. Dort könnte man dann wie bei der Sendersuche
auswählbar machen was für EPG man Cachen mächte (TV/Radio/Alles).

Außerdem könnte man dort die MaxEvents, den Speicherort für die XML
Option auswählen und und und...


Gruß
____Paule

[Nirvana]

sectionsd liest aber die services.xml nicht. s.o. Er weiß ja gar nicht, welches ein Radiosender ist.

[PauleFoul]

sectionsd liest aber die services.xml nicht. s.o. Er weiß ja gar nicht, welches ein Radiosender ist.

Deswegen sollst Du ja als erstes die Zapit in den Sectionsd einbauen!

Das lohnt sich auch für andere Probleme (z.B. PMT-Update)...


Gruß
____Paule

[Nirvana]

Deswegen sollst Du ja als erstes die Zapit in den Sectionsd einbauen!

Doppelpass alleine? Vergiss es.

[PauleFoul]

Is es den so schwer die Zapit in den sectionsd rüber zu nehmen??
Die macht doch garnet so viel oder??

Vielleicht hilft ja Houdini?? Der hat es auf jedenfall auch drauf!

Und wer weiss, wenn mal jemand angefangen hat gibt es bestimmt
eine Eigendynamik.


Gruß
____Paule

[Bimmel]

sectionsd liest aber die services.xml nicht. s.o. Er weiß ja gar nicht, welches ein Radiosender ist.

Alles was nur audiopid hat ist Radiosender und das weiß Sectionsd.