Moin Moin,
ich habe eine Frage zum Charset beim Streammonitor. Welches Format für Metadaten erwartet mAirList?
Icecast unterstützt ja Latin-1 und UTF-8. Bei Umlauten läuft da irgend etwas flasch.
Aus: Alan Silvestri - Back to the Future (Zurück in die Zukunft)
Wird: Alan Silvestri - Back to the Future (Zurück in die Zukunft)
Spiele ich den aber auf meiner Serverinstaz direkt aus, wird das ü korrekt übertragen und auch meine Einspeisung ist ein mAirList Encoder (zur Zeit noch 5.3).
Reicht der StreamMonitor den Tag durch, gerät irgend etwas durcheinander.
Liegt auch nicht spezfisch an diesem Titel, tritt auch bei anderen Umlauten auf.
Kann das etwas mit der Charset Config vom Icecast zu tun haben? http://icecast.org/docs/icecast-2.4.1/config-file.html
Einspeisung und Ausgabe sind unterschiedlichen Mount Points am gleichen Server und haben aktuell keine Vorgabe drin also vermutlich Latin-1 bzw. ISO-habichvergessen als Defultwert.
Sieht zwar lustig aus, wenn man korrekte und falsche Schreibweise auf 2 Mountpoints nebeneinander sieht aber ich möchte doch gernde den richtigen Tag an meine Hörer Ausliefern.
Der Streammonitor verwendet intern exakt dieselben Routinen für die Titelanzeige wie die normalen Stream-Elemente in der Playlist.
Kannst du bitte noch einmal kontrollieren, ob bei der Wiedergabe per Stream-Element (Playlist oder Cartwall) tatsächlich die Umlaute korrekt angezeigt werden? Sowohl im Player als auch auf dem ausgehenden Stream.
Hmm, spannend. Ich bin gestern im Studio nicht dazu gekommen, den Test zu machen und wollte das mal gerade nachholen.
Jetzt, Einspeisung über Altacast und der Titeltag geht sauber durch.
Komischerweise wird der Titeltag auf meinem Einspeise-Mount, bei Umlauten, gar nicht aktualisiert. Der Stream Monitor findet ihn aber und reicht auch korrekt durch.
Ich glaube, das muss ich mir nächste Woche noch mal genauer anschauen und mehr Daten Sammeln. Vielleicht auch noch mal unterschiedliche Encoder durchprobieren, denn anscheinend gibt es da ja große Unterschiede beim Meta Handling.
OK, also wenn ich den Stream in den Player lade, passiert genau das gleiche. Da wird im Player schon der falsche Titel Tag angezeigt.
Das nächste Problem sieht man auch gleich, da die AAC+ Encodierung im Moment nicht funktioniert habe ich ffmpeg als Transcoder eingesetzt und übertrage den Titel aus dem Loggin Interface von mAirlist. Das wird aber nicht durch den High Priority Eingang getriggert.
Ich habe da gerade noch was interessantes entdeckt.
Mein Icecast Logging, das eigentlich deaktiviert ist und trotzdem läuft (anderes Problem), versucht folgendes meldet: 16.07.2017 22:00:11 Fehler HTTP call to http://admin:SicherstesPasswort-Der-Welt@localhost/admin/metadata?charset=UTF-8&mode=updinfo&mount=%2F32k.aac&song=Boulevard%20-Rainy%20Day%20In%20London%20(Full%20Length%20Version) failed: HTTP/1.0 400 Bad Request
Mal abgesehen davon, dass ich die Variablen %1 - %2 übergebe anstatt a% - %b, wird hier UTF-8 encodiert.
Laut Doku war das aber nur in einer der früheren Versionen zwingend und wurde wegen Inkompatibilität der Source-Clients wiederrufen. (Siehe mein Link oben)
For non-Ogg streams like MP3, the metadata that is inserted into the stream often has no defined character set. We have traditionally assumed UTF8 as it allows for multiple language sets on the web pages and stream directory, however many source clients for MP3 type streams have assumed Latin1 (ISO 8859-1) or leave it to whatever character set is in use on the source client system.
This character mismatch has been known to cause a problem as the stats engine and stream directory servers want UTF8 so now we assume Latin1 for non-Ogg streams (to handle the common case) but you can specify an alternative character set with this option.
The source clients can also specify a charset= parameter to the metadata update URL if they so wish.
Ich bin mir nicht ganz sicher, wie ich die Aussage aus der Icecast Doku deuten soll. Wird hier immer eine Übersetzung nach UTF-8 vorgenommen oder nur, wenn der Source Client nicht sagt, dass er UTF-8 überträgt. Mein Test weiter oben mit Butt brachte ja keinen Fehler, bei den 2 bisher getesteten Kollegen die mit SAM einspeisen gab es auch keine Probleme, nur es wurde nicht jeder Titel auch wirklich übertragen.
[quote=“Torben, post:7, topic:11127”]Da steht sinngemäß:
Wenn kein charset-Parameter gesetzt ist, wird UTF-8 (für Ogg) bzw. Latin1 (für nicht-Ogg, also z.B. MP3) angekommen.
Alternativ kann der Source-Client einen charset-Parameter mitsenden, um die Zeichenkodierung explizit anzugeben. Genau das macht mAirList.[/quote]
Ja, so hätte ich das auch gedeutet, die Einspeisung funktioniert ja auch. Erst wenn mAirList den Stream wieder abgreift wird es zerwürfelt. Egal ob ich den Stream mit einem Player abgreife oder über den Stream Monitor. Muss also ein genereller Bug sein.
Was mich nur wundert wenn jemand mit SAM einspeist, dann taucht der Titel mit Umlaut nicht auf der Icecast Statusseite auf, wird aber trotzdem von mAirList gelesen und zwar dann auch noch ohne Fehler.
EDIT: Vielleicht noch wichtig, ich habe zwar als Region Deutschland angegeben aber auf dem Server, keine deutsches Language Pack installiert. Der angemeldete User hat also die Default Englische Oberfläche. Wenn irgend wie möglich möchte ich das auch so belassen, da findet man sich doch deutlich besser zurecht, wie mit der schlechten deutschen Übersetzung der Oberfläche.
EDIT2: Ich habe nun doch das Language Pack installiert, weil die Einstellung schon komplett auf de waren aber das Language Pack nicht drauf war. Mal sehen, ob es einen Änderung brachte, das kann ich leider erst heute Abend testen.
Ich habe das Language Pack vollständig installiert aber das brachte keine Änderung.
Ich habe auch den Titel des Threads angepasst, da das Problem nicht nur beim Stream Monitor auftritt sondern auch bei der normalen Wiedergabe des Quellstreams im Player.
Gut, nebenbei noch eine Interessante Entdeckung gemacht. Das gleiche Problem mit dem Charset besteht auch, wenn ich einen Shoutcast 1.9 Stream abgreife, hat also anscheinend nichts mit der Streamquelle zu tun und auch nicht mit dem Rechner. Bin gerade auf meinem Home-Studio, gleicher Build-Stand wie auf unserem Server. Der Stream lief in einem der Player und wurde dort falsch angezeigt. Das hatte ich im Server ja auch scho so gesehen.
Nach ein paar neuen Informationen, habe ich die Config von meinem Icecast noch mal angepasst.
Ich habe in der Liquidsoap Mailinglist (leider ist der link, den ich mir gespeichert habe defekt) gefunden, dass man die Mountpoints in Icecast gezielt auf UTF-8 setzen sollte.
Das hat zur Folge, dass Icecast immer versucht auf dieses Charset zu konvertieren. Bei Latin1 funktioniert das offensichtlich nicht oder nicht zuverlässig, bzw nicht, wenn man dann UTF-8 schickt, so wie mAirList das ja per Default macht.
Es wurde jedenfalls gesagt, dass einfach die Übertragung mit dem UTF-8 Parameter, nicht ausreicht, wenn Icecast den Mountpoint nicht gezielt als UTF-8 gesetzt bekommt.
Ich schaue mal, ob ich den Beitrag noch mal wieder finde.
Das habe ich nun auch gemacht für alle Mountpoints (Eingabe wie Ausgabe) und seit dem bekomme ich auch das JSON.xsl richtig kodiert ausgegeben und kann per PHP, den Titel korrekt lesen.
Ich würde daraus 2 Dinge ableiten.
[ol][li]Es sollte eine Option im Icecast Encoder geben, ob mAirlist UTF-8 senden soll oder nicht, das habe ich in anderen Encodern auch schon mal so gesehen. Als Default, vielleicht sogar deaktiviert, so wie es auch bei Icecast, Default ist.[/li]
[li]Erwartet der mAirList Player (Playlist Player und Stream Monitor) ein anderes Format als UTF-8 (Latin1?), was per Icecast Default, ja sogar richtig wäre. Hier muss wohl eine Erkennung rein, was da ankommt.[/li][/ol]
Zunächst, wir reden über das Titelupdate des mAirList-Encoders, ja? Also nicht das standalone Icecast-Logging, ja?
Der Encoder aktualisiert den Titel über BASS_Encode_CastSetTitle: BASS Documentation
Dort steht:
The ISO-8859-1 (Latin-1) character set should be used with Shoutcast servers, and UTF-8 with Icecast and Shoutcast 2 servers.
Genau nach dieser Angabe richtet sich mAirList - bei Icecast und Shoutcast 2 übergebe ich der bassenc.dll die Metadaten in UTF8, bei Shoutcast1 in Latin1.
In Wireshark kann ich sehen, dass die bassenc.dll das Titelupdate tatsächlich in UTF-8 codiet aber ohne charset-Parameter in der URL durchführt:
GET /admin/metadata?mode=updinfo&mount=%2Fmini7&song=Thees%20Uhlmann%20-%20Wei%C3%9Fe%20Kn%C3%B6chel HTTP/1.0
Es verlässt sich also darauf, dass Icecast auch UTF-8 erwartet. Tut es aber nicht (unbedingt). Der interessante Satz steht im Changelog von Icecast 2.3.2, siehe http://icecast.org/news/icecast-release-2_3_2/
Default for non-Ogg content is now Latin-1 (aka ISO-8859-1). Ogg content still uses UTF-8.
Frühere Versionen von Icecast haben also immer UTF-8 erwartet bzw. angenommen. Seit Version 2.3.2 (über neu Jahre alt!) wird nun nur bei Ogg noch UTF-8 angenommen, für alle anderen Streamtypen, insbesondere MP3, wird Latin1 erwartet.
Ich werte das mal als Bug in der bassenc.dll. Die sollte immer den charset-Parameter mitschicken (und damit das erreichen, das du jetzt durch das Setzen des charset-Wertes in der icecast.xml gemacht hast). Ich werde das bei Ian reporten.
Die Aussage der Airtime-Entwickler, dass Icecast den charset-Parameter in der URL nicht richtig auswertet, kann ich zumindest mit meinem Icecast-Server (2.3.3 auf Ubuntu 14.04) nicht nachvollziehen. Dort funktioniert der charset-Parameter wie beschrieben. Wenn ich zu o.g. Update noch “charset=utf8” mitgebe, werden die Umlaute korrekt auf der Icecast-Statusseite angezeigt.
Bleibt noch die Frage, was mit den Metadaten des empfangenen Streams ist. Diese werden mittels BASS_ChannelGetTags ausgelesen: BASS Documentation
Ich bin mir nicht sicher, ob BASS zuverlässig erkennt, in welcher Kodierung die Metadaten eines Streams ankommen. In meinem kleinen Test gerade habe ich den erzeugten Stream (mit händisch gesetzten UTF8-Metadaten) direkt wieder als Streamelement in die Playlist eingebunden, und die Umlaute wurden korrekt dargestellt. Hast du ihr andere Erfahrungen?
Ich habe gerade neue Snapshot sowohl für 5.3 als auch 6.0 hochgeladen. Hier gibt es in den Encoder-Einstellung eine neue Dropdown-Box, wo man den Zeichensatz für das Titelupdate einstellen kann.
Standard ist “Automatisch”, also wie bisher - wobei ich nun den Icecast-Client so angepasst habe, dass er für non-Ogg wieder Latin1 verwendet, so wie es ein (nicht angepasster) Icecast erwartet. Alternativ kann man explizit Latin1 oder UTF-8 auswählen.
Ian habe ich gebeten die Dokumentation zu korrigieren.
Ja, gemeint ist der interne Encoder. Beim Icecast logging wird der Parameter für UTF-8 mitgegeben, wobei es natürlich Sinn machen würde, im Encoder und Icecast Logging die gleichen Möglichkeiten zu haben also auch zwischen Latin und UTF-8 Codierung zu wählen. Ist aber für meinen aktuellen Aufbau im Moment nicht erforderlich.
[quote=“Torben, post:15, topic:11127”]Ich habe gerade neue Snapshot sowohl für 5.3 als auch 6.0 hochgeladen. Hier gibt es in den Encoder-Einstellung eine neue Dropdown-Box, wo man den Zeichensatz für das Titelupdate einstellen kann.
Standard ist “Automatisch”, also wie bisher - wobei ich nun den Icecast-Client so angepasst habe, dass er für non-Ogg wieder Latin1 verwendet, so wie es ein (nicht angepasster) Icecast erwartet. Alternativ kann man explizit Latin1 oder UTF-8 auswählen.
Ian habe ich gebeten die Dokumentation zu korrigieren.[/quote]
Dann werde ich den Snapshot mal testen.
OK, wenn ich Auto/ Latin-1 Übertrage, dann funktioniert es. Alles auf UTF-8, bringt im mAirlist Player (normaler Player) immer noch Kodierungsfehler. VLC versteht es richtig.
Screenshot anbei.
Was ich übrigens sehr angenehm finde, dass nach dem umschalten der Kodierung, sofort ein Titelupdate raus geht auch bei laufendem Titel. Macht die Fehlersuche sehr einfach.
Die Serverconfig habe ich nicht geändert, die mounts stehen immer noch auf UTF-8.
Ich kann erst mal mit Latin-1 einspeisen und auch die Moderatoren damit einspeisen lassen, ist die Frage in wie weit es sinnvoll ist, das noch weiter zu verfolgen.
Moment, du bist schon wieder zwei Schritte zu weit
Hast du die -Einstellung aus der icecast.xml jetzt herausgenommen? Solltest du. Und dann den Encoder auf “Automatik” stellen. Dann verhält sich mAirList genauso, wie von Icecast seit v2.3.2 angenommen: UTF8 bei Ogg, sonst Latin1.
Auf der Statusseite und im XSL sollten dann die Umlaute korrekt erscheinen. Kannst du das bestätigen?
Moment, du bist schon wieder zwei Schritte zu weit
Hast du die -Einstellung aus der icecast.xml jetzt herausgenommen? Solltest du. Und dann den Encoder auf “Automatik” stellen. Dann verhält sich mAirList genauso, wie von Icecast seit v2.3.2 angenommen: UTF8 bei Ogg, sonst Latin1.
Auf der Statusseite und im XSL sollten dann die Umlaute korrekt erscheinen. Kannst du das bestätigen?[/quote]
Die Statusseite beim Icecast hat immer 1:1 angezeigt, was mir auch meine mAirlist Server Instanz anzeigt. Was seit der Umstellung auf UTF-8 richtig funktioniert, ist die Ausgabe des Status als JSON. Den rufe ich per PHP ab, wie auch den /admin/stats direkxt als XML, weil ich nur so an die Daten meiner versteckten Einspeisepunkte heran komme. Bei XML spielt die eingestellte Kodierung aber keine Rolle.
Hier noch mal die Bilder von weiter oben
Der AAC Stream ist hier irrelevant, den hatte ich zu der Zeit noch extern mit ffmpeg transkodiert. Wichtig sind nur die Einspeisung, ganz unten und die Ausgabe ganz oben.
Das hat sich auch nicht geändert, nachdem ich die Mount-Points auf UTF-8 in der Icecast.xml umgestellt habe.
Mein Test Aufbau sind mein Home mAirlist und mein Pro mAirlist. Bei beiden habe ich nur die mairlist.exe ausgetauscht. Da vom Zeitstempel her sonst nur noch die FTDI-.dll und die ebur128.dll neu sind, sollte das gehen.
Ich kann das auch umdrehen, der Server spielt normale Rotation und ich gebe den MP3 Stream bei mir einfach nur wieder, dann sehe ich im Player ob die Codierung gut aus sieht oder nicht. Das würde auch 1:1 so wieder beim Icecast ankommen.
UTF-8 habe ich bei allen Mountpoints noch drin und so funktioniert auch alles, solange ich in mAirlist Latin-1 schicke. Du hattest geschrieben, dass der BassEncoder zwar UTF-8 schickt aber den Charset-Parameter nicht mit gibt. Ich vermute mal, das ist auch im neuen Snapshot noch so, wenn ich den Encoder auf UTF-8 festnagle. So wie ich die Doku (BASS Documentation) verstehe, hast Du ja gar keine Möglichkeit dem Encoder zu sagen, diesen Charset=UTF-8 Parameter mitzugeben, was aber erforderlich wäre, wenn ich mp3 schicke und trotzdem UTF-8.
An der Stelle, verstehe ich nicht, was Icecast dann macht, es bekommt UTF-8, erwartet aber Latin-1 und warum wird das was auch immer Icecast daraus macht, vom VLC richtig dargestellt und von mAirlist nicht?
Demnach müsste jetzt (da ich die Mounts noch auf UTF-8 habe) der icecast Server meine Latin-1 Einspeisung in UTF-8 übersetzen, was der Icecast Doku entspricht und was auch zu dem passt, was ich mit der JSON Ausgabe in meinem PHP Script mache.
Ich hatte ja bereits andere Encoder, meiner Moderatoren, die korrekt in der Einspeisung funktioniert haben, ich nehme an, die schicken auch Latin-1.
Das einzige was etwas merkwürdig ist, da suche ich noch nach der Regelmäßigkeit, was aber im live Betrieb etwas schwierig ist, einige Tags werden bei den Einspeisepunkten gar nicht über die Statusseiten von Icecast ausgegeben aber der Player zeigt sie korrekt an und auch an der Ausgabe wird der Titel richtig übertragen. Soll hier aber erst mal nur als Randnotiz stehen bleiben.
Warum tust du das? Das ergibt keinen Sinn. Es ist doch so (ausgehend von einem aktuellen Icecast sowie dem neuesten mAirList-Snapshot):
icecast.xml ohne charset=utf8: Erwartet latin1. Also mAirList auf “Automatik” oder “Latin1” stellen.
icecast.xml mit charset=utf8: Erwartet UTF8. Also mAirList auf “UTF-8” stellen.
Also ist die Einstellung “UTF-8” genau dann zu wählen, wenn der Stream serverseitig auf charset=utf8 gesetzt wurde.
Also mein Vorschlag wäre, charset wieder raus, überall neuesten Snapshot und auf “Automatik”. Dann müsste es passen. So war es zumindest in meinen Tests.
Ich verstehe übrigens die Icecast-Dokumentation so, dass sich die charset-Angabe nur auf die eingehenden Titelupdates bezieht. Wie Icecast dann intern (Statusseite, XSL) und im ausgehenden Stream weiter damit umgeht, das steht da nicht. Ich war bisher davon ausgegangen, dass dann im weiteren Verlauf ausschließlich UTF-8 zum Einsatz kommt. Habe aber inzwischen meine Zweifel. Denn ein Blick in den Icecast-Source verrät, dass die empfangenen Daten nicht etwa fest nach UTF-8 codiert werden, sondern immer in einen “plugin-abhängigen Charset” (wobei plugin hier als “Format” zu lesen ist, also MP3):
value = util_conv_string (in_value, charset, plugin->charset);
Und das scheint bei MP3-Streams wiederum auf Latin-1 zu stehen. Also codiert Icecast die empfangenen Metadaten, egal welchen Charsets, erstmal nach Latin-1. Und schickt sie auch so auf den ausgehenden Stream? Müsste ich testen. In dem Thema stecke ich aktuell noch gar nicht drin.
