mati schrieb
Seit dem letzten Systemupdate (?) kann ich den Stream zwar noch aufrufen, es fangen aber sofort sehr kurzfrequente, rel. laute Klack-Geräusche meiner (SATA)-Festplatte an bis der Stream irgendwann einfriert. Xkill des Frontends bringt dann wieder Ruhe. Kein anderes Programm hat sowas bisher je ausgelöst.
Die klickende Platte ist also am Desktop und klickt nur, wenn du (egal mit welchem Frontend) einen
Stream empfängst, aber nicht wenn du z.B. vom Server oder sonst woher eine Datei auf diese Platte
kopierst?.
Normalerweise sollte der Netzwerk-Stream ja 1:1 (also direkt) abgespielt werden können, oft wird
von den Playern aber auch ein (Festplatten)-Cache genutzt. Dieses "Klacken" könnte also durch
bewegen des Schreib/Lesekopfes herrühren, wenn bei dem Cache-File a) am Ende Daten angefügt
werden und b) gleichzeitig (TimeShift) z.B. in der Mitte gelesen werden muß. Der Kopf also ggf.
oft hin- und herbewegt wird. Allerdings sollte Festplatten/FS-Caching sowas auffangen.
Provozieren (unabhängig von mplayer und Streaming) könntest du sowas evtl. durch:
#!/bin/sh
dd if=/dev/zero of=/pfad/wo_der_stream_zwischengespeichert_wird/testfile bs=1024K count=200 &
# (Hier also einen Zielort auf der Platte/Partition wählen)
sleep 3
dd if=/pfad/wo_der_stream_zwischengespeichert_wird/testfile of=/dev/null
Sowas in der Art als Skript gespeichert und antesten. Das erstellt ein 200MB File im Hintergrund,
wartet 3s und startet dann das Lesen der Datei. DU kannst count= natürlich erhöhen da 200MB
nicht viel sind und ggf. zu schnell kopiert um was zu hören.
Was da am ehesten beim Update in Frage käme wäre ein Kernel-Update, das letzte vor ein paar Tagen
war hier z.B.: kernel26 (2.6.27.5-1 -> 2.6.27.6-1). Was vor dem Zeitpunkt des ersten Auftretens
bei dir updated wurde sagt dir dein pacman.log. Ein Minor-Kernelupdate sollte das zwar nicht
als Ursache haben, aber du hast ja die Möglichkeit eines Downgrades zum Gegentest.