Mit 64MB: Dateiwiedergabe Audioplayer schießt Box ab

[w-sky]

Hallo,

irgendwie ärgerlich: Mit eingebauter Speichererweiterung (Nokia Kabelbox) beendet mit 100% Garantie der Audioplayer bei Wiedergabe von Dateien nach kurzer Zeit effektvoll seine Dienste, die Box fährt runter und schaltet sich ab.

Habe mehrfach das RAM durch Start des Console-Modus getestet, niemals Fehler. (Pfeil hoch beim Einschalten bzw. Reset)
Dann nochmal das letzte Release geflasht (yadi und JtG) und mit Standardeinstellungen getestet, aber immer das gleiche: Mit Beginn des 3. oder des 4. Tracks ist die Wiedergabe gestört, einige Sekunden danach geht der Audioplayer aus und die Box fährt zum Ausschalten direkt runter. Jedoch nur, wenn die Songs in der Playlist nacheinander abgespielt wurden, nicht wenn man die Tracks überspringt. Ob NFS oder CIFS zum Einsatz kommt macht keinen Unterschied. Hier die letzten Console-Meldungen: Beim 3. Song kam der Absturz.

Code: Alles auswählen

[CFSMounter] Mount(0) 192.168.0.4:/mp3 -> /mnt/mp3
addRecursiveDir /mnt/mp3/album
avia_oss: IOCTL: SNDCTL_DSP_SPEED (arg=44100)
avia_av_event: $Id: avia_av_event.c,v 1.11 2003/10/26 16:32:51 obi Exp $
avia_gt_pcm_set_rate(44100)
aviaext: ioctl: Operation not supported
CMP3Dec: recoverable frame level error (lost synchronization)
CMP3Dec: end of input stream
CMP3Dec: recoverable frame level error (lost synchronization)
CMP3Dec: end of input stream
Segmentation fault
 :)
Waiting for controld (max. 5 seconds)
Waiting for controld (max. 4 seconds)
Waiting for controld (max. 3 seconds)
Waiting for controld (max. 2 seconds)
Waiting for controld (max. 1 seconds)
Going to halt system now ...
Starting pid 182, console /dev/console: '/etc/init.d/halt'
CXA2092 found
CXA2092 found
Unmounting 'nfs' on '/mnt/mp3'
Unmounting 'tmpfs' on '/tmp'
umount: Couldn't umount /tmp: No such file or directory
Unmounting 'jffs2' on '/var'
umount: forced umount of /var failed!
Oops: umount failed :-(  --  trying to remount readonly...
Ready to shutdown system...
The system is going down NOW !![ConfigFile] Unable to open file /var/tuxbox/config/controld.conf for writing.[ConfigFile] Unable to open file /var/tuxbox/config/controld.conf for writing.
[yhttpd] !!! SIGNAL !!! :15!
[yhttpd] No special SIGNAL-Handler:15!
[yhttpd] stop requested......
Sending SIGKILL to all processes.
Requesting system halt.

Wohingegen Shoutcast-Radio stundenlang störungsfrei laufen kann - und wenn ich die Erweiterung rausnehme und mit 32MB das selbe Image boote, läuft der Audioplayer (so gut wie) perfekt mit Dateien und Shoutcast-Streams.

Kann mir jemand helfen?? Ich habe das Forum kreuz und quer durchsucht und keine Lösung hierzu gefunden. Wenn es Absturzprobleme mit dem Audioplayer gab, dann eigentlich immer bei Shoutcast und nicht bei Dateien und nicht in Zusammenhang mit der Größe des RAM. Ich möcht mich nicht zwischen EPG++ und Audioplayer entscheiden müssen.

[hannebamb(el)]

hmm, ne nokia kabelbox mit gesteckter 32 mb erweiterung ?
musste die bei nokia nicht gelötet werden und die gesteckte waren nur 16 MB ?

[SoLaLa]

nene...
es gab ja ne menge nokis mit 32MB onboard... aber der stecker war dropsdem da
und dann nimmt man sone alte 16mb steckplatine und lötet da 2 andere chips drauf und n paar jumper umlöten und dann hat man ne noki mit 64mb

[w-sky]

Genau so ist es, 32 MB onboard und auf 32 MB umgebaute Erweiterung (mit Stecksockel). Wird auch korrekt beim Einschalten angezeigt und der EPG "schafft" damit so ungefähr 12.000 Events. Find' ich sehr prima, weil ich seit Jahren schon auf gedruckte Fernsehzeitschriften verzichte.

Aber was ist mit meinem Audioplayerproblem, jemand eine Idee? Wieso gibt es den Absturz nur bei Dateiwiedergabe, hat es vielleicht am Ende etwas mit dem Filesystem zu tun?

Ich habe diesmal mit top in einem Terminal beobachtet, wie es sich währenddessen mit dem Speicher verhält. Anfangs sind ca. 44 MB frei, der Swap (cached) ist 8 MB. Nach dem Start des Audioplayer sind 42 MB frei (10 MB cached). Während die Wiedergabe läuft, geht der verbrauchte Speicher kontinuierlich hoch und der freie Speicher runter. Zum Zeitpunkt des Absturzes sind immer noch ca. 26 MB frei - und ca. 23 MB Swap cached.

Mir sagt das jetzt erstmal nichts außer dass der RAM-Verbrauch doch ziemlich heftig ist.

[SoLaLa]

hmmm, scheint irgendwie der speicher vollzulaufen...
ich denke nicht, daß da irgendwas hardwareproblemmäßiges vorliegt.
vielleicht sollte der Thread mal woanders neu eröffnet werden
neutrino oder kernel oder so....

[w-sky]

Naja, dass der Audioplayer ein Memory Leak hat, ist eigentlich keine Neuigkeit, und auch ohne RAM-Erweiterung wird der Speicher aufgefressen und nicht wieder freigegeben.

Ich habe das ganze nochmal mit top bei ausgebauter Erweiterung beobachtet: von zuerst 12 MB frei und 8 MB Swap cached gehen die Werte nach dem Start des Audioplayers auf 11 frei / 8,5 cached und pendeln sich dann nach 10-15 Minuten auf ca. 0,5 MB frei / 19 MB cached ein. Und da bleiben sie dann, stundenlang ohne Absturz!

Daher kann ich nicht ausschließen, dass es am RAM liegt. Gibt es nicht eine Möglichkeit, das RAM noch intensiver als mit der Boot-Konsole zu testen??

[SoLaLa]

hmmm, könnte möglich sein, daß das RAM n schuß hat...
passiert der Absturz immer an der Stelle wo noch gesamt 26MB frei sind?

ich weiß jetzt nicht wie der Speicher da im einzelnen genutzt wird, aber das sieht dann etwa so aus, als ob genau bei der Hälfte der Erweiterung der Absturz kommt (42MB-26MB)

[w-sky]

Genau kann ich das nicht sagen, weil die Anzeige von top auch ein bisschen verzögert kommt und Box und PC bei mir in verschiedenen Zimmern sind; so 100% kann ich das nicht synchronisieren.

Es scheint nicht exakt die selbe Stelle zu sein: Bei verschiedenen Tests bin ich durchaus auf 1-2 MB weniger bzw. mehr bei beiden Werten gekommen. Die obigen Werte sind Mittelwerte.

[sagemol]

Also:
Habe das ganze mal auf meiner Sagem Sat 1x 64MB getestet.
Ja, der Speicher läuft voll, allerdings stürzt die Box bei mir nicht ab.
Wobei das bei mir dann so aussieht:

Mem: 62032K used, 1276K free, 0K shrd, 164K buff, 39468K cached

Oder auch so:

/autofs/mp3 # free
total used free shared buffers
Mem: 63308 62276 1032 0 192
Swap: 0 0 0
Total: 63308 62276 1032
/autofs/mp3 #

Aber voller wirds nicht.
MP3s abgespielt über nen CIFS-Mount über automounter.
Wobei sich mir der erweiterte Sinn verschliesst, warum da eigentlich soviel "gecached" wird.
Das Dingens muss doch linear, also sequentiell lesen, also warum cachen ?
Könnte man die Cachegrösse von demjenigen, der hier cached, konfigurierbar machen ?
Erstmal rausfinden, wer das ist....
Denn der Speicher wird auch nach beenden des Audioplayers nicht freigegeben.
Ist mir aber bei Aufnahme oder Wiedergabe via NFS-Mount beim Movieplayer auch schon aufgefallen.
Scheint vom Kernel selber zu kommen oder aber mit den Filesystemen zu tun zu haben.
Ich habe den automounter mit timeout=600. Wenn der timeout zieht,
also der mount physikalisch wieder weg ist, ist auch der Speicher wieder frei.

Greez !

[w-sky]

Hi, ich habe mal versucht herauszufinden, was es mit dem "cached"-Wert überhaupt auf sich hat. Beste Erklärung war hier: http://www.linuxhowtos.org/System/Linux ... gement.htm

Großer Irrtum meinerseits: "cached" hat nichts mit "Swap" zu tun, das steht bei top nur aus Platzgründen in der selben Zeile. Der Cache ist ein reiner Dateicache, während Swap ja - üblicherweise - die Auslagerungspartition bei Linux ist, bei der Tuxbox aber gar nicht vorhanden.

Wenn ich es dann richtig verstanden habe, verwendet Linux bei Dateizugriffen immer so viel RAM wie möglich als Dateicache, verschiebt dafür aber - anders als Windows - Programmdaten nicht ins Swap (bzw. Pagefile). Selbst wenn der Speicher bis auf ein kleines Limit voll als Dateicache verwendet wird, stört es das System oder andere Programme gar nicht, weil der Speicher sofort wieder freigegeben wird, wenn ein Programm Speicher anfordert. (Und wie in Sagemols Beispiel, wenn das gecachte Laufwerk unmountet wird...)

Folglich ist es nur normal, dass bei Dateiwiedergabe das freie RAM bis auf ein Minimum herunter geht, denn freies RAM <> verfügbares RAM.
Mit dem "cached" hab ich also selbst eine falsche Fährte gelegt.

Und bin jetzt noch ratloser als zuvor. Wenn gar nicht der Audioplayer das RAM verwendet, sondern Linux ganz wie es sein sollte bloß sein Dateicache schreibt, ist jetzt die Frage, wieso es dann immer ein segmentation fault gibt und wieso das System dann sofort runterfährt.
Wie finde ich heraus, woher der segfault (*) kommt? Es sieht so aus, als ob der Audioplayer gar nicht abstürzt, sondern einfach durch den erzwungenen system halt beendet wird!!

Gibt es diesen core dump (s.u.)?

* segmentation fault: An error in which a running Unix program attempts to access memory not allocated to it and terminates with a segmentation violation error and usually a core dump. (The Free Online Dictionary of Computing (http://foldoc.doc.ic.ac.uk/))

[SoLaLa]

ich tippe immer noch auf das RAMmodul

[TbM]

Windows ist hier auch mit einem art "Segmentation Fault" abgestürzt (es versuchte auf Speicherbereiche zuzugreifen die nicht erlaubt waren), nachdem ich den RAM-Takt im Bios von 133mhz auf 130mhz geändert habe läuft Windows wieder (jetzt seit 3 Wochen nonstop)...

Liegt wohl am RAM welches die Daten nicht behält die hineingeschrieben werden... ein paar 00er werden dann zu Adressen auf die der Kernel nicht zugreifen darf aber will...

[Gorcon]

Wenn der MP3 Player öfters abstürzt, sollte man Metadatenparsing abschalten, das hat bei mir hier geholfen.

Gruß Gorcon

[w-sky]

War aus, und bei Shoutcast gibt es zudem gar keine Probleme.

Der Audioplayer stürzt nicht ab, wie ich nun ja bei genauerer Beobachtung feststellte - es sieht nur so aus, weil ein system halt-Signal ihn zum Beenden und Neutrino zum Runterfahren zwingt.
Fragt sich jetzt, woher das "Going to halt system now ..." aus obigem Log kommt.

[SoLaLa]

CMP3Dec: recoverable frame level error (lost synchronization

ja nu, logmäßig passiert die Ursache an der Stelle. Die geholten Daten sind korrupt und deshalb verliert der mp3player den Stream... so seh ich das zumindest

[sagemol]

Jep, und da muss ich SoLaLa kräftig unterstützen:

Der SegFault deutet mit an Sicherheit grenzender Wahrscheinlichkeit auf Bit-Kipper im RAM hin.
Oder aber auf einen ziemlich schlechten Kontakt am RAM-Sockel,
kalte Lötstelle beim RAM selber oder ähnliches.
Auf alle Fälle ist der Fehler im RAM Bereich zu suchen, denke ich.

Greez !