sectionsd memoryfree bei movieplayer und audioplayer

[Günther]

Könnte man im cvs nicht grundsätzlich beim Start des Movieplayers/Audioplayers den sectionsd speicher löschen (über memoryfree)? Den EPG braucht man da doch eh nicht, und beim zurückschalten wartet man eben ein paar Sekunden auf das Update ...

Ich habe es jedenfalls in mein Image so eingebaut...

[usul1]

Und dann auch noch beim Start der Aufnahme.
Jedenfalls geht Sectionsd UND die NFS Direktaufnahme bei mir nicht zusammen. Im Moment kille ich auch den Sectionsd bei Aufnahmestart. Leider fehlt dann der Filmtitel im Dateinamen.

cu
usul

[Günther]

Dafür müßte aber eine neue Löschfunktion in den sectionsd, die zumindest das current/next event des aktuellen Senders nicht löscht, sonst ist der Effekt der Gleiche wie beim sectionsd killen. Dann fehlt nämlich z.B. auch der EPG für den MB und das fände ich ziemlich suboptimal

[usul1]

Dafür müßte aber eine neue Löschfunktion in den sectionsd, die zumindest das current/next event des aktuellen Senders nicht löscht,

Na, beim Sectionsd finden sich ja immer schnell Leute die sowas mal eben schnell nebenbei einbauen ;-)

sonst ist der Effekt der Gleiche wie beim sectionsd killen. Dann fehlt nämlich z.B. auch der EPG für den MB und das fände ich ziemlich suboptimal

Oder Neutrino (oder der timerd) merkt sich die EPG Info der geplanen Aufnahme bevor er timer.start aufruft (Da kille ich den z.B.).
Aber AFAIK werden die EPG Infos eh in der timerd.conf gespeichert. Eigentlich sollte es ja jetzt schon so gehen.

BTW: Wie löscht du denn den sectionsd Speicher ohne den sectionsd zu modefizieren? Gibts da ne bessere Methode als killall?


BTW2: Was IMHO wirklich gut wäre, wäre ein systemweites "Jetzt werden alle Recourcen gebraucht dies gibt" Signal (Gibts sowas wie WMs unter Linux?).
Dieses müssten alle Programme auswerten und daraufhin nach eigenen Ermessen handeln.
Z.B. sollte Neutrino daraufhin den Teletext Cache löschen und das Cachen deaktivieren. Tuxmaild sollte aufhören auf Mails zu prüfen. Sectionsd sollte seinen Speicher leeren und aufhören neue Daten zu sammeln. D.h. alle Programme die das Netzwerk, die CPU und den Speicher belasten sollten vorrübergehend auf Sparflamme gehen bis das Systemweite "OK, macht alle weiter" Signal kommt.

cu
usul

[Z80]

statt immer und immer mehr drumrumgefrickel und drangebastel (insbesondere am sectionsd) sollte mal lieber die ursächlichen bugs gefixt werden.
glaubt ihr ernsthaft, dass neutrino durch weitere dirty-hacks stabiler wird?
wenn ihr bei jeder x-beliebigen aktion den sectionsd abgeschiessen wollt, hier ein vorschlag: laßt ihn doch ganz weg und ladet ihn erst gar nicht.
über die ganzen "killall -TERM sectionsd" bei jeder x-beliebigen aktion kann man nur noch den kopf schütteln.
ich jedenfalls hab keine lust permanent wieder auf den EPG warten zu müssen weil der beim
- aufnahmestart abgeschossen wird
- beim movieplayerstart
- beim audioplayerstart
usw. usf.
um dann beim restarten jedesmal die cpu-last gen 150% zu treiben.
aber bitte - jeder nach seiner fasson.

[dietmarw]

... sollte mal lieber die ursächlichen bugs gefixt werden.
glaubt ihr ernsthaft, dass neutrino durch weitere dirty-hacks stabiler wird? ...

auf deutsch.. alles komplett neu schreiben..

wer hat
a: die zeit dazu (plus lust natürlich)
und fast noch wichtiger
b: kann das denn auch noch vernüftig

.. du??

sooo einfach ist das alles nicht..

[usul1]

statt immer und immer mehr drumrumgefrickel und drangebastel (insbesondere am sectionsd) sollte mal lieber die ursächlichen bugs gefixt werden.

Was ist gegen eine saubere Signalisierung einzuwenden? Das kleine RAM der Box ist ja kein Bug.

Fakt ist, der Speicher der Box ist festgelegt. Weiterhin braucht man zu fehlerfreien Aufnahme eine möglichst großen Buffer.
Ferner ist es blödsinn den Speicher fest unter den Anwendungen aufzuteilen.
Also was spricht dagegen wenn der Sectionsd sich den ganzen verfügbaren Speicher nimmt um möglichst viel EPG zu speichern, aber das er, wenn er mitbekommt das Speicher für eine Aufnahme gebraucht wird, seinen Speicher freigibt?

Die Box ist ja schließlich kein WinXP PC wo man einfach noch nen GB Speicher reinpackt wenn die Programierer mal wieder keine Lust hatten mit den Speicher vernünftig zu haushalten.

Was ist ferner dagegen einzuwenden Systemweit zu signalisieren das das Netzwerk zur Aufnahme benötigt wird damit alle anderen Programme die auch das Netzwerk benutzen vorrübergehen ihre Aktivität einstellen?

glaubt ihr ernsthaft, dass neutrino durch weitere dirty-hacks stabiler wird?
wenn ihr bei jeder x-beliebigen aktion den sectionsd abgeschiessen wollt, hier ein vorschlag: laßt ihn doch ganz weg und ladet ihn erst gar nicht.
über die ganzen "killall -TERM sectionsd" bei jeder x-beliebigen aktion kann man nur noch den kopf schütteln.

Besser als nicht Aufnehmen zu können weil der Aufnahmepozess wegen Speichermangel abbricht.

Immerhin habe ich dank dieser killall Aktion, über die du den Kopf schüttelst, ein EPG UND fehlerfreie Aufnahmen (die halt ohne EPG Infos).

cu
usul

[Günther]

CSectionsdClient::freeMemory() (also g_Sectionsd->freeMemory() )löscht im sectionsd den Speicher. Ist alles schon drinnen, nur wird es noch nirgends benutzt/aufgerufen. Anonsten wird der sectionsd bei audio/movie/aufnahme eh schon schlafen geschickt.

Besser wäre halt wenn nicht alles gelöscht wird sondern nur ein wenig .

Das mit der höheren Prozlast müßte man für die freememory methode noch mal beobachten.

Bin da aber im Moment recht pragmatisch, bei mir ist es im Image drinnen. Um die Frage, ob das ins cvs soll, könnt Ihr euch ja gegenseitig die Köpfe einschlagen, ich halte mich da lieber raus ... .

[Z80]

Besser als nicht Aufnehmen zu können weil der Aufnahmepozess wegen Speichermangel abbricht.

wegen speichermangels ist mir noch seltenst eine aufnahme nicht geglückt. das hatte i.d.R. andere gründe (z.b. die berühmte meldung, es wäre noch ein anderer aufnahme prozess aktiv.
insofern sind fehlerhafte aufnahmen nicht eindeutig ursächlich auf speichermangel zurückzuführen!

Anonsten wird der sectionsd bei audio/movie/aufnahme eh schon schlafen geschickt.

DAS ist ja auch akzeptabel und wird prakitiziert. wodurch aber natürlich kein speicherfrei geräumt wird, sectsionsd krallt sich aber zumindest solange keinen neuen und die prozessorlast sinkt natürlich.

Um die Frage, ob das ins cvs soll, könnt Ihr euch ja gegenseitig die Köpfe einschlagen, ich halte mich da lieber raus ... .

wie ich schon sagte: jeder wie er mag

[usul1]

Besser als nicht Aufnehmen zu können weil der Aufnahmepozess wegen Speichermangel abbricht.

wegen speichermangels ist mir noch seltenst eine aufnahme nicht geglückt. das hatte i.d.R. andere gründe

Schalte mal das Teletaxt cachen ein und setze die Cache Werte für den Sectionsd vernünftig hoch. Dann kannst du eine Aufnahme mit 99 Ringbuffern starten und sehen wie sie scheitert (Kein Wunder wenn beim Aufnahmestart einfach kein Speicher mehr frei ist).

Nun gut, ich kann das teletext cachen abschalten und den sectionsd so einstellen das er nur 10 events speichert. Aber dann gammelt der schöne Speicher ja auch nur unnütz rum wenn gerade keine Aufnahme läuft. ;-)

Es sollte doch wirklich möglich sein den vorhandenen Speicher sinnvoll zu nutzen (Und da ist das killen des Sectionsd vor der Aufnahme die einzige Möglichkeit das zu tun ohne das man selber programmieren muß). D.h. natürlich nur in Form eines Wunsches. Das da tatsächlich was passiert, daran glaube ich auch nicht wirklich.
Irgenwie ist das halt doch alles Gebastel. Die einzelnen Programme sollten wirklich mal anfangen vernünfig miteinander zu reden


Also von da aus wäre ich über Günthers freememory im CVS schon glücklich (Man kanns ja konfigurierbar machen).

cu
usul

[PauleFoul]

Nach oben schieb...

[Lior]

bei monstern wie sectionsd empfehle ich die benutzung von einem garbage collector. z.B. boehm-gc mit LD_PRELOAD könnte wunder wirken ;-)

[MajorK]

auf deutsch.. alles komplett neu schreiben..

wer hat
a: die zeit dazu (plus lust natürlich)
und fast noch wichtiger
b: kann das denn auch noch vernüftig

Es gab ja mal einen Ansatz von Homar, die ganzen Memory-Leaks zu stopfen (IIRC). Das hat dann irgendwann schlagartig aufgehört.

Ein langer Thread dazu ist z.B. hier:
http://forum.tuxbox-cvs.sourceforge.net ... hp?t=39689
inbesondere:
http://forum.tuxbox-cvs.sourceforge.net ... ht=#285011

Leider hat sich Homar dann lange (ca. 1 Jahr) nicht mehr gemeldet. Vielleicht kann ein cvs-Checker ja mal nachsehen, ob nach dem 15.1.2006 Änderungen von Homar ins CVS gewandert sind / oder jemand der Kontakt zu Homar hat(te) fragt zumindest nach dem letzten Stand...

0,02ct,
Major K.

[Lior]

ich hab mir den code angeschaut, dieser code ist voodoo! es ist sogar leichter, sectionsd from scratch zu schreiben.

[Houdini]

er ist wahnsinning, oder genial, wahrscheinlich beides