2023-01-17T14:41:29 cbxk1xg

[...] Bei einem icecast HTTP-Stream wird die Verbindung jedoch über die gesamte Zeit aufrecht erhalten und die Nutzdaten werden solange gesendet bis ein anderes Ereignis eintritt. Erst am Ende der Übertragung, durch stoppen des Streams im Browser oder durch das kicken das Clients am Server, wird der HTTP Status Code gesendet. Bricht die Verbndung ab wird gar kein Status Code gesendet.

Das kann so nicht stimmen. Die erste Zeile einer HTTP-Antwort ist der Status Code, erst danach kommt der Inhalt.

Vielleicht meinst Du ja HTTP-Streaming? Dazu gibt es Standard-Entwürfe (im Wikipedia-Artikel verlinkt). Da zerlegt der Server die Medien in "Segmente" und der Client setzt die zusammen, es laufen also mehrere HTTP-Requests, um eine MP3-Datei zu übertragen. Der Content-type bei solchen Protokollen ist nicht audio/mpeg!

Das prinzipielle Problem Deines Codes bleibt aber bestehen: Wenn Du mit LWP::UserAgent ein get ausführst, dann blockiert das so lange, bis der komplette Inhalt der URL übertragen wurde. Und wenn der Server kontinuierlich sendet, dann... passiert das nie, und Dein Code hängt an der Stelle. Wie Du ja gemerkt hast.

Also: Schau' Dir an, welchen Content-type Header Deine Quelle schickt und lies nach, wie man den behandeln muss. Möglicherweise brauchst Du nicht-blockierende Lösungen für den Client (zum Beispiel Mojo::UserAgent mit seiner Methode get_p) und für den Server, um "portionsweise" Daten austauschen zu können.

Noch ein Hinweis zum Thema

Quote

und dann an beliebig viele User verteilt.

Darauf ist Dein Code nicht gut eingerichtet. Du beginnst mit dem "Saugen" erst, wenn ein Request eintrudelt und holst die Medien dann bei jedem weiteren Request für die gleiche URL erneut. Da wäre vermutlich ein Cache angebracht? Oder eben ein Live-Streaming (wie beim Radio), bei dem die, die sich später zuschalten eben den Anfang verpassen?