Icecast-Konfiguration

Status
Für weitere Antworten geschlossen.
Hallo,
Ich hab mich gerade bei eurem Forum angemeldet, da ich eine frage habe. Und zwar kann ich nichts an meinen Radio senden, da der Maunt Point wahrscheinlich ein Problem hat. Kann sich jemand bitte die Zeit nehmen und sich mal die Konfiguration ansehen. Vielen Dank im Voraus.
Code:
<icecast>
    <!-- location and admin are two arbitrary strings that are e.g. visible
        on the server info page of the icecast web interface
        (server_version.xsl). -->
    <location>Vienna</location>
    <admin>Amann Sebastian</admin>
 
    <limits>
        <clients>100</clients>
        <sources>2</sources>
        <threadpool>5</threadpool>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>10</source-timeout>
        <!-- If enabled, this will provide a burst of data when a client
            first connects, thereby significantly reducing the startup
            time for listeners that do substantial buffering. However,
            it also significantly increases latency between the source
            client and listening client.  For low-latency setups, you
            might want to disable this. -->
        <burst-on-connect>1</burst-on-connect>
        <!-- same as burst-on-connect, but this allows for being more
            specific on how much to burst. Most people won't need to
            change from the default 64k. Applies to all mountpoints  -->
        <burst-size>65535</burst-size>
    </limits>
 
    <authentication>
        <!-- Sources log in with username 'source' -->
        <source-password>user</source-password>
        <!-- Relays log in username 'relay' -->
        <relay-password>user</relay-password>
 
        <!-- Admin logs in with the username given below -->
        <admin-user>admin</admin-user>
        <admin-password>Passw0rd!</admin-password>
    </authentication>
 
    <!-- set the mountpoint for a shoutcast source to use, the default if not
        specified is /stream but you can change it here if an alternative is
        wanted or an extension is required
    <shoutcast-mount>/live.ogg</shoutcast-mount>
    -->
 
 
    <!-- This is the hostname other people will use to connect to your server.
    It affects mainly the urls generated by Icecast for playlists and yp
    listings. -->
    <hostname>xxxxxxxx</hostname>
 
    <!-- You may have multiple <listener> elements -->
    <listen-socket>
        <port>8000</port>
        <!-- <bind-address>127.0.0.1</bind-address> -->
        <shoutcast-mount>/stream</shoutcast-mount>
    </listen-socket>
    <!--
    <listen-socket>
        <port>8001</port>
    </listen-socket>
    -->
 
    <!--<master-server>127.0.0.1</master-server>-->
    <!--<master-server-port>8001</master-server-port>-->
    <!--<master-update-interval>120</master-update-interval>-->
    <!--<master-password>hackme</master-password>-->
 
    <!-- setting this makes all relays on-demand unless overridden, this is
        useful for master relays which do not have <relay> definitions here.
        The default is 0 -->
    <!--<relays-on-demand>1</relays-on-demand>-->
 
    <!--
    <relay>
        <server>crimson.nssbe.at</server>
        <port>8001</port>
        <mount>/example.ogg</mount>
        <local-mount>/live.ogg</local-mount>
        <on-demand>0</on-demand>
 
        <relay-shoutcast-metadata>0</relay-shoutcast-metadata>
    </relay>
    -->
 
    <!-- Only define a <mount> section if you want to use advanced options,
        like alternative usernames or passwords
 
    -->
 
    <fileserve>1</fileserve>
 
    <paths>
        <!-- basedir is only used if chroot is enabled -->
        <basedir>/opt/icecast/2.3.3/share/icecast</basedir>
 
        <!-- Note that if <chroot> is turned on below, these paths must both
            be relative to the new root, not the original root -->
        <logdir>/home/amann/icecast2/var/log/icecast</logdir>
        <webroot>/home/amann/icecast2/share/icecast/web</webroot>
        <adminroot>/home/amann/icecast2/share/icecast/admin</adminroot>
        <!-- <pidfile>/opt/icecast/2.3.3/share/icecast/icecast.pid</pidfile> -->
 
        <!-- Aliases: treat requests for 'source' path as being for 'dest' path
            May be made specific to a port or bound address using the "port"
            and "bind-address" attributes.
          -->
        <!--
        <alias source="/foo" destination="/bar"/>
          -->
        <!-- Aliases: can also be used for simple redirections as well,
            this example will redirect all requests for http://server:port/ to
            the status page
          -->
        <alias source="/" destination="/status.xsl"/>
    </paths>
 
    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
        <!-- <playlistlog>playlist.log</playlistlog> -->
          <loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
          <logsize>10000</logsize> <!-- Max size of a logfile -->
        <!-- If logarchive is enabled (1), then when logsize is reached
            the logfile will be moved to [error|access|playlist].log.DATESTAMP,
            otherwise it will be moved to [error|access|playlist].log.old.
            Default is non-archive mode (i.e. overwrite)
        -->
        <!-- <logarchive>1</logarchive> -->
    </logging>
 
    <security>
        <chroot>0</chroot>
        <!--
        <changeowner>
            <user>nobody</user>
            <group>nogroup</group>
        </changeowner>
        -->
    </security>
</icecast>
 
Sagen wirs mal so:

Wenn ich gar keinen
deklariert hätte, könnte auch ich
nichts an meinen Radio senden

Es wundert mich aber auch gerade gar nicht, dass dir das entgangen ist, denn deine XML-Datei kann kaum ein Mensch lesen. Sechs KB Text, von denen gerade mal ein Drittel Konfigurationsinformationen für den Icecast sind. Alles andere sind Kommentare, die nicht nur (r)eine Resourcenverschwendung darstellen, sondern auch die Lesbarkeit beinträchtigen und damit die Fehlerquote erhöhen. Besonders schlimm wird das dann, wenn man zur Bearbeitung solcher Dateien keinen Editor benutzt, der Syntaxhighlighting beherrscht (z. B. ConText f. Windows, unter Linux hat man meist schon etwas wie gedit o.ä.).

Über andere Informationen in der Datei kann man sich streiten, vor allem darüber, wie sinnvoll es ist, seinen (oder fremde) Klarnamen hier zu veröffentlichen, den eigenen (oder fremden) Servernamen zwar wegzuixen, aber dafür andere stehen zu lassen und gleich die Passwörter mitzuliefern. Das ist alles etwas sehr wenig durchdacht und ich hoffe für dich, dass dir solche Leichtfüßigkeit nicht mal irgendwann auf die Füße fällt.

Dann frage ich mich auch, unter welchem Betriebssystem der Server laufen soll. Ohne Userwechsel dürfte er unter Linux normalerweise nicht einmal starten, ggf. lehnt er auch den Dienst ab, wenn er nicht die notwendigen Rechte zum Zugriff auf die Logfiles hat. Sollte er mit dieser Konfig also überhaupt laufen, dann vermutlich nur unter Windows.
Wenn dem so ist und es überhaupt zur Ausführung kommt, dann wird es vermutlich genügen, einfach den Mountpoint zu deklarieren, der dem "Shoutcast-Port" bereits zugewiesen wurde:
Code:
    <mount>
        <mount-name>/stream</mount-name>
    </mount>

Für weiterführende Optionen zum Mounting und Mountpointdeklarationen liest du bitte die ausführliche Dokumentation auf icecast.org.
 
Vielen dank für deine Antwort. Die Passwörter waren nur zum testen da und deshalb war es mir egal. Allerdings hast du natürlich recht mit der aussage bezüglich der öffentlichen Darstellung. Bezüglich des Servers, es sollte alles unter einem CentOS laufen. Ich habe die konfig jetzt noch einmal überarbeitet und jetzt müsste Sie eigentlich passen. Könnte sie vielleicht nochmal jemand ansehen und mir sagen ob sie jetzt passt.
Code:
<icecast>
    <location>xxxxxxx</location>
    <admin>xxxxxxx</admin>
 
    <limits>
        <clients>100</clients>
        <sources>2</sources>
        <threadpool>5</threadpool>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>10</source-timeout>
        <burst-on-connect>1</burst-on-connect>
        <burst-size>65535</burst-size>
    </limits>
 
    <authentication>
        <source-password>xxxxxxx</source-password>
        <relay-password>xxxxxxx</relay-password>
        <admin-user>xxxxxxx</admin-user>
        <admin-password>xxxxxxx</admin-password>
    </authentication>
 
    <hostname>xxxxxxx</hostname>
 
    <listen-socket>
        <port>8000</port>
        <shoutcast-mount>/stream</shoutcast-mount>
    </listen-socket>
 
    <fileserve>1</fileserve>
 
    <mount>
        <mount-name>/stream</mount-name>
        <username>xxxxxx</username>
        <password>xxxxxx</password>
    </mount>
 
    <paths>
        <basedir>/opt/icecast/2.3.3/share/icecast</basedir>
        <logdir>/home/amann/icecast2/var/log/icecast</logdir>
        <webroot>/home/amann/icecast2/share/icecast/web</webroot>
        <adminroot>/home/amann/icecast2/share/icecast/admin</adminroot>
        <alias source="/" destination="/status.xsl"/>
    </paths>
 
    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
          <loglevel>3</loglevel>
          <logsize>10000</logsize>
    </logging>
 
    <security>
        <chroot>0</chroot>
    </security>
</icecast>
 
Was möchtest du mit
Code:
<username>xxxxxx</username>
<password>xxxxxx</password>
im mount-Tag erreichen? Einen pwd-geschützten Stream? Dann wird das so nicht funktionieren, weil Icecast Benutzer und Passwörter irgendwo speichern muss, du aber nicht angibst, wo und wie das passieren soll. Siehe Dokumentation (mount -> authentication).

Und: Es hat wenig Sinn, uns hier allgemein zu fragen, ob die Konfiguration in allen Punkten zu einer Funktion des Servers führt, die deinen Erwartungen entspricht. Wie oben schon angedeutet, verhält sich Icecast unter verschiedenen Linux-Distributionen anders als unter Windows, von Portierungen auf spezielle Systeme oder Nicht-x86-Maschinen mal noch gar nicht gesprochen, wo einzelne Funktionen entweder gar nicht verfügbar sein oder gar zum Absturz führen können.
 
OK Danke, dann las ich den pwd-geschützten vorübergeheng weg. Danke aber für deine Tipps falls ich noch ne spezifische Frage habe werde ich mich melden.:)
 
Sechs KB Text, von denen gerade mal ein Drittel Konfigurationsinformationen für den Icecast sind. Alles andere sind Kommentare, die nicht nur (r)eine Resourcenverschwendung darstellen, sondern auch die Lesbarkeit beinträchtigen und damit die Fehlerquote erhöhen.

Ich muss den Threadersteller mal etwas in Schutz nehmen.


Was er dort gepostet hat, war mehr oder weniger das Standard-Konfigurations-Template von icecast. Also das, was man als /etc/icecast2/icecast.xml erhält, wenn man das icecast2-Paket unter Linux installiert. (Bei der Windows-Distribution vermutlich ähnlich - die benutze ich nicht).

Solche Beispielkonfiguration sind häufig mit vielen auskommentierten Einstellungen versehen, damit der Benutzer schnell sieht, was grundsätzlich zu konfigurieren möglich wäre - aber nicht konfiguriert werden muss. Ich finde das meisten sehr praktisch, weil es eine Art "eingebaute Dokumentation" ist.

Leider sind Kommentare in XML-Dateien (also die Blöcke mit <!-- -->) so eine Sache - sie sind wesentlich weniger lesbar als "handelsübliche" #-Kommentare in Text-Konfigurationsdateien (z.B. Apache).

Apropos "nicht konfigurieren müssen": Das ist bei den Mountpoins von icecast grundsätzlich der Fall. Man muss sie nicht extra in der Konfiguration definieren, sondern sie werden dynamisch angelegt, sobald ein Source-Encoder sie mit Daten beschickt. Deswegen steht im Template auch: "Only define a <mount> section if you want to use advanced options, like alternative usernames or passwords"

Bei einer Neuinstallation von icecast reicht es daher meistens, das Template zu nehmen und lediglich die Passwörter für source, relay und admin anzupassen. Ggf. noch den Namen des Adminstrators und die maximale Anzahl sources.
 
Apropos "nicht konfigurieren müssen": Das ist bei den Mountpoins von icecast grundsätzlich der Fall.
Solange man propere Upstream-Klienten benutzt, also solche, die entsprechend Icecast2-tauglich arbeiten, ist das auch richtig. Es wird aber deutlich schwieriger, wenn man wie ich (und der TE sah das offenbar auch vor) praktisch nur mit Shoutcastklienten upstreamen möchte, vielleicht auch noch mit mehreren Mounts arbeiten und Fallbacklösungen einbringen möchte.

Ich für meinen Teil habe mir angewöhnt, die XML-Konfigs so sauber und logisch zu schreiben, dass sie sich lesen wie ein Programm bzw. ein Script. Dann muss ich nicht ein Rätselraten veranstalten, ob die einzelen Streamer richtig konfiguriert sind. Ein Blick in die Konfig sagt mir: "DAS macht der Server gerade!". Und wenn irgendwo etwas nicht läuft, dann liegt es dementsprechend nicht am Icecast.
 
danke für die Infos .
Apropos "nicht konfigurieren müssen": Das ist bei den Mountpoins von icecast grundsätzlich der Fall. Man muss sie nicht extra in der Konfiguration definieren, sondern sie werden dynamisch angelegt, sobald ein Source-Encoder sie mit Daten beschickt. Deswegen steht im Template auch: "Only define a <mount> section if you want to use advanced options, like alternative usernames or passwords"
Also bedeutet das um an icecast zu stremmen benötigt man keine Mountpoints.Außer man möchte einen pwd-geschützten Stream starten. Stimmst das So?
 
So wie es bereits zu lesen war.

Übrigens funktioniert das sogar entgegen meiner ursprünglichen Befürchtung bei Shoutcast-Mounts. Es genügt also, unter listen-socket einen Mountnamen für einen Shoutcast-Upstream mit shoutcast-mount zu deklarieren. Auch dieser wird dann automatisch angelegt.
 
Leider hab ich jetzt noch ein Problem und zwar kann ich mittels traktor 2 meine Musik zum Radio streammen und es wird auch angezeigt auf der Homepage. Allerdings kann ich die Musik mit keinem Client anhören. Meine konfig beim icecast ist nun folgendermaßen:
Code:
<icecast>
    <location>Vienna</location>
    <admin>xxxxxxx</admin>
 
    <limits>
        <clients>100</clients>
        <sources>2</sources>
        <threadpool>5</threadpool>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>10</source-timeout>
        <burst-on-connect>1</burst-on-connect>
        <burst-size>65535</burst-size>
    </limits>
 
    <authentication>
        <source-password>xxxx</source-password>
        <relay-password>xxxx/relay-password>
        <admin-user>xxxx</admin-user>
        <admin-password>xxxx</admin-password>
    </authentication>
 
    <hostname>xxxxxx</hostname>
   
    <listen-socket>
        <port>8001</port>
    </listen-socket>
   
 
    <fileserve>1</fileserve>
   
    <paths>
        <basedir>/opt/icecast/2.3.3/share/icecast</basedir>
        <logdir>/home/amann/icecast2/var/log/icecast</logdir>
        <webroot>/home/amann/icecast2/share/icecast/web</webroot>
        <adminroot>/home/amann/icecast2/share/icecast/admin</adminroot>
        <alias source="/" destination="/status.xsl"/>
    </paths>
 
    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
          <loglevel>3</loglevel>
          <logsize>10000</logsize>
    </logging>
 
    <security>
        <chroot>0</chroot>
    </security>
</icecast>

Und in der Playlist welche heruntergeladen werden kann steht folgendes:
Code:
http://servername:8001/
Vielen Dank im voraus.
 
Wäre zwar grundsätzlich soweit richtig, allerdings fehlt natürlich der Mountpoint.
Code:
http://servername:8001/mountname
wäre richtig.
Ein deutliches Zeichen, dass der Server auf dem OS eben entweder doch nicht richtig arbeiten kann (XML-/XSLT-lib-Konflikte), oder du noch andere Fehler an anderen Stellen verbaut hast, die sich aus der Konfig so nicht mehr erschließen. Traktor macht doch auch nur Ogg, oder? Dann wäre die Frage, ob der Icecast überhaupt mit den entsprechenden Bibliotheken dafür kompiliert wurde.
Ab hier beginnt das Verfahren "Glaskugel", aber wir sind keine Wahrsager.

btw:

<burst-size>65535</burst-size>
Ist genau eins zuwenig. Das Burst-Paket sollte genau 64 KB groß sein, also 65536 Bytes.
 
Vielen Dank für die Hilfe :thumbsup:.
Wenn ich den Fehler finde werde ich in hier posten.
images

Sorry musste sein.
 
Hab den Fehler.
Der Fehler war das der Client nicht wusste das er im OGG Format empfangen soll. Um das Problem zu lösen habe ich einen Mountpoint mit der Endung .ogg erstellt nun funktioniert alles. :)
 
"Mountpoint.ogg" machen einige Streamer sogar automatisch. Es merkt sich nur halt kaum jemand, welche genau. Dies vor akllem, weil OGG massiv (und nicht ganz umsonst) an Popularität verloren hat.

Insofern du aber wenigstens die Problemlösung hier kundgetan hast, verdienst du schon fast ein Bienchen ins Muttiheft. Das hat leider Seltenheitswert.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben