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.