Ja, der Stream läuft durch, der Webplayer bleibt einfach stehen und möchte dann nicht mehr. Und auch nur im Webbrowser, ich werde jetzt gleich nochmal Edge und Firefox testen, das muss ich zugeben habe ich noch nicht gemacht.
Und das ist ja das was mich wirklich Stutzig macht, mit meinem Gemieteten Stream24 funktioniert es ja auch ohne Probleme und da habe ich einen
Icecast 2KH und beim Stefan hatte es auch nicht Funktioniert, da waren die Ausfälle auch.
Nun nochmal zum Endbericht! Firefox über 1,5 Std ohne Probleme, Opera auch über 50 Minuten ohne Probleme, Chrome und Edge machten beide nach ein paar Minuten Feierabend. Den ich euch nun auch wünsche wenn es soweit ist!
Auf dem Mac mit Chrome passiert es übrigens nicht.
Meine Vermutung ist, dass die Chromium-Browser unter Windows einen von Windows (Media Foundation) bereitgestellten Decoder benutzen, der irgendwie buggy ist.
Sowas hatten wir in der Vergangenheit auch schon mit der AAC-Wiedergabe in mAirList ohne installierte bass_aac.dll (die mAirList aus patentrechtlichen Gründen nicht mitliefern darf).
Ich habe mal testweise eine halbe Stunde die Rohdaten aus dem HTTP-Stream mit cURL mitgeschnitten. Währenddessen lief der Stream auch bei mir im Browser ohne Unterbrechung durch.
Wenn ich die mitgeschnittene *.ogg-Datei nun wieder zum Abhören in den Browser lade, spielt sie erst, aber nach Ende des ersten Liedes stoppt die Wiedergabe.
Wenn man sich die Daten im Hex-Editor anschaut, sieht man, dass an der Stelle ein Titelupdate stattgefunden hat:
Nun muss man verstehen, wie Titelupdates in Ogg-Containern (also Vorbis aber auch Opus) funktionieren.
Im Unterschied zu MP3 ist es bei Ogg nicht möglich, mitten im Stream ein Metadaten-Paket für das Titelupdate unterzubringen. Sondern Metadaten können ausschließlich ganz am Anfang des Streams in einem “Vorbis Comments”-Paket mitgeschickt werden.
Für Titelupdates innerhalb eines Streams behelfen sich die Streamingserver (wie Icecast) nun dadurch, dass sie den Stream in mehrere “logische” Streams unterteilen. Also den ersten Stream beenden und direkt einen neuen anfangen, mit neuem Header davor. So als hätte man zwei Ogg-Dateien “aneinandergeklebt”.
Offenbar kommen die von Chrome und Edge verwendeten Codecs damit nicht klar.
@Micha19721 Kannst du mal testweise das Titelupdate für den Ogg-Stream deaktivieren? Läuft der Stream dann durch?
EDIT: Was mich gerade wundert ist, dass dort im Hexdump auch weitere Metadaten-Felder zu sehen sind, die mAirList eigentlich gar nicht mitschickt - läuft der Stream jetzt gerade überhaupt mit mAirList? Oder ist da aktuell ein Auto-DJ am Werk? Dann müsste man später nochmal testen.
Es senden alle mit ogg und der Auto DJ auch soweit mir bekannt ist. Nur zur Information, ich habe im Mairlist jetzt mal Titelupdate ausgemacht und bis jetzt läuft der Stream 25 Minuten ohne Probleme und lass ihn mal weiterlaufen.
also ich streame jetzt seit einer Stunde und das ohne Probleme, habe in mairlist jetzt nur das Logformat aus dem Titel update rausgemacht und es läuft.
Danke Torben.
Jetzt ist es schriftlich im Forum, man kann danach suchen und es mit einem Lesezeichen versehen.
Dabei beziehe ich mich auf mein nicht mehr so oft abgerufenes Hintergrundwissen aus früheren Zeiten:
Hier ist die Erklärung vom Profi:
Um es nochmal herauszuarbeiten: ogg ist ein Containerformat, in dem meistens Vorbis untergrebracht ist, daher “Ogg (Vorbis)”.
Das muss aber nicht immer so sein, daher folgende… Randnotiz:
Im ogg-Container kann auch OPUS drin sein. Wir hatten das hier im Forum mal in Bezug auf WhatsApp-Sprachnachrichten.
Micha hatte Stefan ja (indirekt) selber zitiert:
Jetzt haben wir was zitierfähiges von Torben.
Ich empfehle ein Lesezeichen.
ok, mag ja sein das wenn ich es richtig verstehe ogg nicht der Nabel der Welt ist, wie nichts im leben und trotzdem verstehe ich nicht warum ICH dann mit Sam Broadcaster 3 Std ohne Probleme gerade gestreamt habe und mit mairlist funktioniert es leider im Moment einfach nicht nicht?
Entweder verstehe ich da was falsch, oder aber ich bin mit der Technik nicht so versiert, das ich ganz einfach nicht mitkomme.
Wenn es mir egal wäre, dann würde ich jetzt abschließen und in Zukunft mit Sam senden, ist es mir aber nun mal nicht! Und davon mal abgesehen, weiß ja keiner ob in Zukunft es nochmal jemanden betrifft, immerhin kam es bei mir ja auch von heut auf morgen nach ein paar Jahren.
Das hat mit dem Nabel der Welt nichts zu tun. Jeder hat seine Präferenzen, sei es nun mp3, Opus oder flac.
Wenn man’s auf die Spitze treibt, könnte man jetzt auch noch dogmatisch über 44,1 oder 48 kHz streiten (in einer anderen Diskussion stellte sich heraus, dass es mit mAirList beim Streaming da keine Resamplimg-Artefakte gibt).
Damit bin ich beim Kern des Pudels: Was andere Software-Hersteller machen, kann ich nicht beurteilen. Allerdings hat sich da in der letzten Zeit mein Erfahrungsschatz (teils negativ) erweitert.
mAirList nutzt die BASS-Bibliothek von Un4seen. Was andere Hersteller nutzen, weiß ich nicht.
Allerdings kommen andere Hersteller aus anderen Ländern mit anderen rechtlichen Rahmenbedingungen und es soll sogar welche geben, denen Rechte Dritter schlicht und ergreifend egal sind.
Spacial, der Hersteller von SAM, sitzt in “central USA”, wenn man der Zeitzone glauben darf (UTC -6). Vielleicht nutzen die ganz andere Systeme, gehen aber nicht transparent damit um.
Jetzt mal ein ganz gewagter Vorschlag: RadioBOSS (leider populär, aber kein ernstzunehmender Konkurrent von mAirList, vor allem nicht, wenn man ein Pult im Einsatz hat) nutzt ebenfalls die BASS-Bibliothek. So steht es zumindest auf deren Seite.
Du könntest die Testversion nutzen und auf diese Art und Weise den Fehler eingrenzen: Tritt es dort auch auf, ist es BASS. Wenn nicht, wäre es mAirList.
Wiegesagt, das ist eine gewagte These, aber ein lustiges Ausschlussverfahren.