Könnte das vielleicht etwas mit den TCP Parametern zu tun haben?
Bei Kernel 2.6 kann man ja unter /proc/sys/net/ipv4/... einiges einstellen. Das müsste doch beim 2.4 auch irgendwie gehen.
Ich erinnere mich daß ich mal Probleme mit einer gewissen Datenbank von einem bekannten Hersteller hatte. Da hat der tolle transparent failover treiber erst nach 4 Stunden umgeschaltet, weil die timeout und retry Parameter etwas ungünstig gesetzt waren. Leider weis ich nicht welche das genau waren. Aber folgende klingen doch nicht schlecht:
tcp_retries1
tcp_retries2
tcp_syn_retries
tcp_synack_retries
tcp_keepalive_time
tcp_keepalive_probes
tcp_keepalive_intvl
Hab mal ein wenig mit madplay und wget rumgespielt. Der wget in busybux kennt die --timeout option nicht.
wget -O -
http://190.40.182.79:8000 | /var/hdd/playground/bin/madplay -
Führt beim Neustarten des Routers auch zu einem Hänger.
Mit dem "richtigen" wget und --timeout
/var/hdd/playground/bin/wget --timeout 10 -O -
http://190.40.182.79:8000 | /var/hdd/playground/bin/madplay -
merkt er es und bricht dann ab.
wget man page:
"The default read timeout is 900 seconds."
"By default, there is no connect timeout, other than that implemented by system libraries."
"The default is to retry 20 times, with the exception of fatal errors like "connection refused" or "not found" (404), which are not retried."
Die timeouts und retries von wget haben zwar nix mit unserem Audioplayer zu tun, aber im Kernel sind die defaults ähnlich hoch.