Icecast2: ständiges Cachen der Clients, viel zu schnelle Wiedergabe

[derlym]

Hallo,

Ich habe testweise einen Icecast2-Server unter Debian laufen. Der Icecast-Server wird von Winamp und dem eddcast-Plugin mit einem MP3-Stream (128kbps, Mono) gefüttert. - Das funktioniert soweit ohne Probleme.

Aber statt den Stream konstant wiederzugeben, cacht der Client den Stream und gibt ihn in einem viel zu hohen Tempo (ungefähr so, als würde man eine Kassette beim Vorspulen wiedergeben) aus. Nach 3-5 Sekunden fängt der Client wieder an, den Stream in den Cache zu laden und gibt ihn erneut viel zu schnell wieder.

Bei einem Test mit dem Windows Media Player, zeigte dieser eine Bitrate von 165kbps, statt der tatsächlich gestreamten 128kbps an.

In der error.log des Icecast-Servers tauchen folgende Einträge auf:

[2009-06-12  12:09:32] DBUG slave/_slave_thread checking master stream list
[...]
[2009-06-12  14:57:21] DBUG stats/modify_node_event update node total_bytes_read (9333549)
[...]

Beide Meldungen treten jeweils unzählige Male auf.
Habt ihr eine Idee, wo der Fehler liegen könnte?

 

[djrick]

Ich würde erstmal die Einstellungen vom Streamer überprüfen:
Wieviel khz sind denn eingestellt?
Konstante kbit oder variable?

Funktionierts mit anderen Stream plugins, wie: Shoutcast

128 kbit und MONO? Also wenn man schon in 128 kbit streamt, dann kann man sich die paar Byte für Stereo ja wohl auch noch leisten

 

[derlym]

Gestreamt wird mit 44100Hz und einer Variablen Bitrate.
Mit Shoutcast habe ich es bereits probiert - Damit konnte ich mich nicht einmal mit dem Server verbinden.
Sind Shoutcast und Icecast2 überhaupt miteinander kompatibel? U.A. vermisse ich bei Winamp's Shoutcast die Einstellungen für den Mountpoint.

Die Übertragung in Mono hat einen anderen Hintergrund: Der Stream soll auf einen Lautsprecherwagen wiedergegeben werden, wo ich lieber ein Joint-Stereo hätte.

Ein Test mit AAC brachte nur ein kurzes Knirschen, ansonsten das gleiche Phönomen, wie beim MP3-Stream.
Mit OGG hingegen funktioniert es einwandfrei - wenn auch mit 10 Sekunden Verzögerung.

Der Client läd die nächsten 10 Sekunden des Streams bereits in den Cache. - Lässt sich dieser Wert auch auf 2-3 Sekunden zurückfahren?

// Nachtrag:
Ein MP3-Stream (Stereo) mit 128kbps funktioniert einwandfrei. Offenbar hat der Server ein Problem mit dem Mono-Stream: Dort tritt der Fehler auf.

Bleibt nur noch die Frage: Warum?