Hallo zusammen,
wollte nur kurz die Ursache für die Abstürze zum Besten geben. Grund für die Weghänger sind (natürlich) meine eigenen Modifikationen an der Box. Ich habe eine Hand voll Shell-Skripte laufen, die automatisch das Audio-Delay oder das Seitenverhältnis setzen. Dafür verwende ich die HTTP-API, um zu erkennen, ob die Box gerade eingeschaltet oder im Standby ist, auf welchem Sender sie gerade steht oder welcher Codec gerade abgespielt wird. Z.B.:
senderinfo=$(wget "http://localhost/web/getcurrent" -q -O -)
nkanal=$(echo "$senderinfo" | grep e2servicename | head -n 1)
Wenn ich meine Skripte weglasse, läuft die Box auch während eines Transfers und bei massiver paralleler WebIf-Verwendung ohne zu zucken. Werfe ich aber währenddessen ein paar Testskripte an, die einfach nur Abfragen wie o.g. Beispiel absetzen, ist es nur eine Frage der Zeit, bis sich die Box weghängt. Scheinbar gibt es ein Limit, was die Box an parallelen Zugriffen verträgt. Ist das überschritten, schießt sie sich ab.
Wo es möglich war, habe ich die Erkennungen auf Daten in den /proc-Strukturen umgestellt. Z.B. die Standby-Erkennung:
modus=$(cat /proc/stb/avs/0/input)
if [ "$modus" == "encoder" ]; then ...
Leider lässt sich nicht alles von dort ermitteln (wie z.B. Sender- oder Sendungsname) und jeder Zugriff auf die HTTP-API lässt die Box kurz pausieren (z.B. merkbar beim Blättern durch die Programmliste), weshalb ich auch schon versucht habe, mich mit der Pyton-API zu befassen, aber da fehlt mir bisher irgendwie noch der Einstieg zur Verwendung der vorhandenen Klassen und Funktionen...
Es ist also kein generelles Problem bei Netzwerktransfers (sonst hätten sich bestimmt auch mehr Leute beklagt).
Trotzdem Danke
C.
EDIT: Sorry, doch wieder neue Erkenntnis, heute hatte ich wirklich nur den Transfer per CIFS laufen und die Box hing sich nach ca 100GB weg...