Jugendschutz im SportPortal!?!?

Beitrag von **zexma** » Samstag 10. September 2005, 12:52

Beim sectionsd/nhttpd liegt immer noch einiges im argen.
Neben der o.g. Probleme ist mir noch folgendes aufgefallen.
Bild

zur Sortierung:
Es muß nach Startzeit sortiert werden, nicht nach EPGID

Houdini hat geschrieben:zur Sortierung:
Es muß nach Startzeit sortiert werden, nicht nach EPGID

Hast du das schon gefunden wieso immer die gleichen Events angezeigt werden auf den Feeds in der Infobar?

Das wär mit eine Kiste virtuelles Bier wert

Riker

JtG-Riker hat geschrieben:
Houdini hat geschrieben:zur Sortierung:
Es muß nach Startzeit sortiert werden, nicht nach EPGID
Hast du das schon gefunden wieso immer die gleichen Events angezeigt werden auf den Feeds in der Infobar?

Das wär mit eine Kiste virtuelles Bier wert

Riker

Mir auch...

Was haben den diese Meldungen zu bedeuten? Sind das die Debugger??

Code: Alles auswählen

[sectionsd] readNbytes: received POLLERR
[sectionsd] read: Value too large for defined data type

Gruß
____Paule

Beitrag von **Npq** » Samstag 10. September 2005, 21:29

Das heißt eigentlich, daß der Demux nicht schnell genug gelesen werden konnte und ein EOVERFLOW aufgetreten ist.

[sectionsd] readNbytes: received POLLERR

den hab ich auch öfters, ist aber immer von der EIT Pid.

Das wär mit eine Kiste virtuelles Bier wert

Sorry, aber heute ist ein schwarzer Tag für mich, nachdem Premiere die NFL Rechte gekickt hat

hab ich keinen Bock mehr, ich muß mich erstmal wieder sammeln.

Aber morgen abend hab ich ja jetzt Zeit (s.o.), vieleicht schau ich es mir mal an.

Ich weiß zwar nicht, ob es überhaupt etwas mit dem fehlenden Speicher-Problem zu tun hat, aber ich poste meine Beobachtung trotzdem.

Nach dem Start der Box, umschalten aufs Sport- und Direkt-Portal, um die EPG-Informationen zu sammeln, habe ich noch ca. 10 MB freien Speicher. Heute habe ich dann festgestellt, dass nachdem ich mir eine Aufnahme mit dem Movieplayer angesehen habe, der freie Speicher plötzlich auf ca. 16 MB gestiegen ist.

Offensichtlich wird vor dem Start des Movieplayers etwas gestoppt und nach dem Beenden wieder reaktiviert. Vielleicht hilft das ja zur Fehlersuche.

Beitrag von **rasc** » Sonntag 11. September 2005, 01:35

... nach eine bisschen Zappen verbraucht der sectionsd locker mal 12MB RAM. Das ist ein bisschen viel, weil soviel EPG wird nun wirklich nicht gesendet (denke ich mal) ;-)

Wenn dann nur noch 300-400 KB Speicher in der Box frei ist, wird das dann wirklich etwas eng. Wenn dann einige Prozesse keinen Check auf freien/zugewiesenen Speicher machen, oder unbedingt Speicher brauchen, dann hat man eine mehr oder weniger abgestürzte Box.

der verbrauch von 12MB ram scheint auch völlig unabhänig von

static long secondsToCache = 21*24*60L*60L;
static long oldEventsAre = 180*60L;

zu sein.
ich habe die werte mal testweise auf 7 tage und 60 minuten gesetzt, aber nach etwa 24h betrieb hatte ich auch damit

..................total.........used.........free.......shared......buffers
Mem:........30900........30160........740...........0...........2292
Swap:...........0..............0..............0
Total:........30900.......30160.........740

wobei doch eigentlich die gesammelten daten viel kleiner sein müssten, als bei 21/180

regards
Innu

Der sectionsd brauchte auch auch schon vor dem Portalpatch soviel Speicher auch egal ob 7, 14 oder 21 Tage.
Wie rasc schon gesagt scheint einer der neuen Prozesse den Speicher nicht zu checken und die Box semmelt ab.
Leider gibts mit neusten CVS auch nicht mehr wie ein segment fault im Bootlog.

Wenn man hier schaut sieht das ja ganz so aus als ob der EIT Thread solange aufgerufen wird bis der Speicher platzt: http://forum.tuxbox-cvs.sourceforge.net ... hp?t=38136&

@nico
dein logging im link sieht sehr nach diesem fehler aus:

[dmx.cpp:read:184] read(fd, buf, n): Connection timed out
zap failed!
[dmx.cpp:read:184] read(fd, buf, n): Connection timed out
zap failed!

wann und wieso der demuxer abstürtzt kann ich nicht nachvollziehen oder reproduzieren ... irgendwann ist der fehler auf einmal da

Innu

Innuendo hat geschrieben:@nico
dein logging im link sieht sehr nach diesem fehler aus:

[dmx.cpp:read:184] read(fd, buf, n): Connection timed out
zap failed!
[dmx.cpp:read:184] read(fd, buf, n): Connection timed out
zap failed!

wann und wieso der demuxer abstürtzt kann ich nicht nachvollziehen oder reproduzieren ... irgendwann ist der fehler auf einmal da

Innu

Ne bei mir stürtzt der demuxer nicht ab, da bin ich mir sicher.

Ich wollte mit meinem obigen Posting eigentlich nur aussagen, dass es mich wundert, wo der Speicher von ca. 6 MB plötzlich herkommt. Irgendetwas muss wohl durch Starten oder Stoppen des Movieplayers ausgelöst werden. Werden denn irgendwelche Prozesse beim Start des Movieplayers angehalten und nach dessen Beenden wieder weiter ausgeführt?

Beitrag von **Nico 77** » Montag 12. September 2005, 22:56

Kann es sein das mit aktuellen Stand das ganze EPG flüssiger läuft, mir kommt es so vor seit den letzten Änderungen beim EPG im CVS.

Aufgefallen ist mir allerdings das bei Direktfilm auf Fragezeichen gedrückt öfters keine Informationen zum Film abfragbar sind.
Leider hat sich am Segmentfault verhalten nichts geändert.

Edit 13.10.05:

Nico 77 hat geschrieben: Aufgefallen ist mir allerdings das bei Direktfilm auf Fragezeichen gedrückt öfters keine Informationen zum Film abfragbar sind.

Hierzu ist mir noch aufgefallen das die Portalzeiten nun wieder ab und zu erst durch hin/her Schalten wie früher aktualisiert werden.

Ps: Könnte mal einer ein FAQ schreiben wie man Linux dazu bringt das man sectionsd/neutrino debuggen kann. Der secfault nervt.

ich hab grad nen neggisches log bei aufnahme gemacht.

[neutrino.cpp] executing /var/tuxbox/config/recording.start.
Record channel_id: 210085002e epg: 210085002e06b9, apids mode 1
SPTS, queue 0 extended.
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process neutrino
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process neutrino
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process neutrino
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
RPC: sendmsg returned error 105
nfs: RPC call returned error 105
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process timerd
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)

sieht aus nach speicher alle

__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process neutrino

Den hab ich die letzte Zeit auch des öfteren gesehen.

Der sectionsd giert in letzter Zeit nur so nach RAM. (Blöd das es für philips keine Speichererweiterung gibt.)

Könnte man in den sectionsd nicht mal so'ne Art "Speicherbegrenzung" bzw. eine Speicherfreigabe einbauen falls das verf. RAM einen best. Level unterschreitet?

Naja, vielleicht mal eine effizientere Speicherverwaltung im sectionsd nutzen.
Die C++-Template-Klassen sind zwar nett, aber nicht gerade speicher-optimiert - leider.

Bin noch dran, ich zieh mir seit 2 Wochen die ganzen c++ Templates Sachen rein.
Derjenige der sich den sectionsd und die Eventverwaltung ausgedacht hat ist schon ein gerissener Hund hat aber von embedded Anforderungen (vor allem Speicherhaushalt) nicht viel gehalten.

Hab mir mal überlegt eine dynamischs secondsToCache einzubauen, d.h. wenn immer mehr events gecached werden (bzw Speicher verbraucht wird) dann wird secondsToCache reduziert und somit fliegen Events die zu weit in der Zukunft liegen wieder raus -> mehr freier Speicher.

Ich habe aber auch den Verdacht daß auch die Speicherfragmentierung hierbei eine Rolle spielt

Houdini

Houdini hat geschrieben:Bin noch dran, ich zieh mir seit 2 Wochen die ganzen c++ Templates Sachen rein.
Derjenige der sich den sectionsd und die Eventverwaltung ausgedacht hat ist schon ein gerissener Hund hat aber von embedded Anforderungen (vor allem Speicherhaushalt) nicht viel gehalten.

... zu der Zeit waren EPGs noch nicht sooo verbreitet und ausserdem hatte der sectionsd den Speicher der Box ja fast fuer sich alleine gehabt. Ansonsten mag die Aussage ueber "fnbrd" wohl stimmen..

Houdini hat geschrieben: Hab mir mal überlegt eine dynamischs secondsToCache einzubauen, d.h. wenn immer mehr events gecached werden (bzw Speicher verbraucht wird) dann wird secondsToCache reduziert und somit fliegen Events die zu weit in der Zukunft liegen wieder raus -> mehr freier Speicher.

Ich habe aber auch den Verdacht daß auch die Speicherfragmentierung hierbei eine Rolle spielt

Houdini

... werden nicht die "alten" Events nur freigegeben?
Bei SecondsToCache werden die Events, zu zu fern sind doch gar nicht erst eingebucht, oder?

Aber sinnvoller waere es die Speicherverwaltung zu reorganisieren - aber da haetten wir ja wieder das Thema neuschreiben....

Bei SecondsToCache werden die Events, zu zu fern sind doch gar nicht erst eingebucht, oder?

genu, aber man kann doch genausogut events die zu weit in der Zukunft (secondstocache) liegen vom housekeeping wieder rausnehmen (removeNewEvents() analog zu removeOldEvents())

Hab gerade ein paar Zeilen geschrieben, mal schauen

Beitrag von **mb405** » Freitag 16. September 2005, 16:48

oh toll. ich sag doch Houdini lässt sich da was einfallen.
ich seh in den code nicht so durch, aber ne configurierbarkeit (wie viele tage im vorraus) der epg gespeichert wird, wäre net schlecht. ich brauch eh nur den epg für heute und morgen.

mb405 hat geschrieben:oh toll. ich sag doch Houdini lässt sich da was einfallen.
ich seh in den code nicht so durch, aber ne configurierbarkeit (wie viele tage im vorraus) der epg gespeichert wird, wäre net schlecht. ich brauch eh nur den epg für heute und morgen.

Nicht wirklich sinnvoll, da selbst wenn du nur 3 Tage Vorschau vom sectionsd lesen lässt, schreibt dieser den Speicher trotzdem voll.
Alles schon probiert....

Beitrag von **rasc** » Freitag 16. September 2005, 18:48

Houdini hat geschrieben:
Bei SecondsToCache werden die Events, zu zu fern sind doch gar nicht erst eingebucht, oder?
genu, aber man kann doch genausogut events die zu weit in der Zukunft (secondstocache) liegen vom housekeeping wieder rausnehmen (removeNewEvents() analog zu removeOldEvents())

Hab gerade ein paar Zeilen geschrieben, mal schauen

Naja, IMO löst das das Problem nicht wirklich. Das ist wieder die Sache mit Ursache und Symptom...

... selbst wenn man die Zeit fuer den EPG nach unten verringert (was eigentlich nicht Sinn eines EPGs ist), bekommt man das Problem durch zappen ueber die verschiedenen Sender wieder auf den Tisch, ueber je mehr Sender man zappt, umsomehr EPG-Eintraege kommen wieder. Um es mal ironisch auszudruecken, man koennte natuerlich auch das Zappen auf andere Sender verhindern, wenn der Sectionsd voll laeuft...

12 MB Speicher ist eine ganze Menge (man druecke das mal in gespeicherten Buchstaben aus!) - in 12 MB bekommt man eigentlich den EPG für "mehrere Jahre" rein...

Code: Alles auswählen

Naja, IMO löst das das Problem nicht wirklich. Das ist wieder die Sache mit Ursache und Symptom...

korrekt, aber vielleicht immer noch besser als ein Absturz!?
ich habe gestern verzweifelt versucht, mehr als 6MB zu verbrauchen und habe dabei gezappt wie ein großer - nix.
Irgendwie ist das auch Tagesform abhängig, grummel.

@rasc
was ist denn das mit den 10(oder11) EIT Filtern?
was bedeutet dass, wofür wird das benutzt?
muss man das machen?

in 12 MB bekommt man eigentlich den EPG für "mehrere Jahre" rein...

ich habe mal getestet

Code: Alles auswählen

gezappt #events #gemallokt
RTL       240 events    155000 Bytes
+Premiere1    705       661000
+Premiere2   764      739000
+Sportportal   911      844000
+ARD      4202      2461000
+ZDF      6891      3743100
+ORF      7400      3887560
+SkyItaly   7725      3980000
+Digital+   7900      4028000
+Premiere   11057      4461000

2. Versuch
+Premiere1   514      567000
+RTL      749      692000
+Premiere2   768      728000
+Premiere   3940       2031000