Shoutcast 2 different port

Deutsch / German mAirList 6.x
1

Ich versuche Shoutcast so zu konfigurieren, dass ein zweiter stream über einen anderen Port gesendet wird.
Wenn ich portbase_2=8000 setze erkennt Shoutcast den zweiten Stream ignoriert aber die unterschiedliche Port Adresse und sendet beiede Stream auf 8000 mit unterschiedlichen Pathnamen.
Wenn ich Portbase_2 auch auf den anderen Port lege, wie im Internet zu finden ist, ignoriert Shoutcast den zweiten Stream oder er kommt nicht an.
Hier der Teil der Konfiguration.

streampath_1=stream
streampath_2=private
serverport_1=8000
serverport_2=8444
portbase_1=8000
portbase_2=8444

Hat jemand Erfahrung damit?

2

Geht mit Shoutcast nicht. Für einen anderen Port muss eine neue Instanz von Shoutcast erstellt werden.

3

Ich habe nur kurz rein gelesen aber die Doku von Shoutcast 2 sagt da etwas anderes. Die betreffende Seite wurde im Januar 2020 zuletzt aktualisiert, sollte also nicht veraltet sein.

Es ist schon lange her, dass ich das mal benutzt habe aber ich meine mich zu erinnern, dass ich seiner Zeit mehrer Ports benutzt habe. Die wurden dann aus kompatibilitätsgründen, auch auf den neuen Icecast übernommen.

4

Ich habe es auch so gelesen. Kannst Du mal den Link der Seite einstellen?
Die Dokumentation ist manchmal etwas dürftig. So musste ich serverip_x durch destip_x ersetzen um Warnings zu vermeiden. Außerdem bekomme ich bei serverport_x immer noch eine Warnung, obwohl es so in der Doku steht.
Wenn zwei unterschiedliche portbase_x habe kann ich beide Streams nur auf den ersten port schicken. Über den zweiten Port nimmt Shoutcast keinen Stream an.

Hilfe ist immer willkommen.

5

Google wirft mir bei der Suche nach shoutcast dnas 2 documentation als ersten Punkt, diese Seite aus:
http://wiki.shoutcast.com/wiki/SHOUTcast_DNAS_Server_2#Configuration_File

Weiter unten im gleiche Dokument steht auch die Portbase erklärt. Die braucht man demnach nur für die veralteten Shoutcast v1 source clients und dementsprechend kann es nur eine Portbase geben. Im Beispiel ist Port 8000 gesetzt, das bedeutet dass ein Shoutcast v1 Source Client auf Port 8001 connecten würde, um dort seine Daten anzuliefern.

Lösung also Shoutcast v1 Quellen eleminieren und nur echte Shoutcast v2 Clients verwenden.

Wozu überhaupt der Kopfstand mit zusätzlichen Ports? Warum nicht einfach weitere streams auf dem existierenden Port?

Wird so wie Du es gemacht hast, natürlich auch nicht funktionieren, weil Du keine Stream ID vergeben hast, sondern nur einen Stream Path, siehe Sektion „Stream Configuration“.

Nachdem ich mit Icecast sehr glücklich bin, ist diese wirre Art der Konfiguration zwar sehr unlogisch für mich aber immerhin steht alles in der Doku.

Edit: Beim noch mal drüberlesen ist mir aufgefallen… Kann es sein, dass es je nach Version, die Config Option „Portbase“ gar nicht mehr gibt? Dass das in irgend einer Version durch „Serverport“ ersetzt worden ist?
Im Wiki wird auf Beispiel Configs verwiesen, die mitinstalliert werden, was steht denn da drin?

6

Shorty danke,
das ist genau das Dokument das ich auch verwendet habe.
Aber da fangen schon die Probleme an. Serverip_x generiert Warnings, man muss destip_x um die Warnungen zu verhindern.
Auch serverport_x generiert Warnings. Steht aber so in der Doku!
portbase** : Specify the port which clients and sources need to use to connect to the server *[Default = 8000]
Aber was ist dann serverport_x?
Sollte dann eigentlich der Port sein auf welchem gesendet wird, oder?
Wenn ich aber auf portbase sende und unterschiedliche serverports definiere, wird nur auf der portbase gesendet aber mit unterschiedlichen streampathes.
Ich habe am Anfang auch IceCast verwendet, war aber nicht befridigend. Hatte am Ende von Liedern immer kurze Unterbrechungen. Außerdem gibt es Icecast nur als x86, welches recht viel Resourcen gefressen hat, ein vielfaches von Shoutcast im x64 Mode.

7

Im allgemeinen hilft, Warnungen lesen verstehen und beurteilen.
Ist es nur eine Warnung, dann ist es kein Fehler, Funktion müsste also vorhanden sein.

:joy: :rofl: Icecast soll ressourcenhungrig sein?
Alles aber das nicht. Während ich mit Shoutcast 2, einen vServer an sein Limit gebracht habe kann ich mit dem gleichen Server x-hundert Connections handeln. Aktuell läuft mein Haupt-Icecast auf einem CPU Kern mit 256MB RAM zugeteilt inkl. Betriebssystem und der Container langweilt sich, Aktueller Speicherverbrauch steht bei 24MB.

Ob eine Software x86 oder nativ x64 kompiliert wird, hat keinen Einfluss auf den Speicherverbrauch, mAirlist ist auch als 32Bit (x86) Anwendung kompiliert, funktioniert ebenfalls Problemlos auf x64 Betriebssystemen, so wie jede andere x86 Software auch auf x64 Betriebssystemen funktionieren.
Das wurde hier im Forum auch schon mehrfach thematisiert.

Der einzige Nachteil einer x86 Anwendung: Sie kann nur bis zu knapp unter 4GB Speicher adressieren. Ich schätze mal, bevor also Icecast diese 4GB Speicher auslastet, ist die Bandbreite im Rechenzentrum ausgereizt, die haben nämlich meistens nur 1GBit Anbindung (pro Server).

Im übrigen ist die Aussage, dass es Icecast nur als x86 Kompilationen gibt, schlichtweg falsch. Für jede gängige Linux Distribution gibt es Sowohl x86 als auch x64 Formate es gibt sogar arm64 Kompilate.

Dass Icecast Titel abschneidet kann technisch gar nicht sein, weil Icecast nur das durchreicht, was eingespeist wird, so wie Shoutcast auch. Der Fehler muss also woanders gelegen haben.
Würde es da ein Problem geben, hätte ich bei uns massive Probleme, mit unzufriedenen Moderatoren.

Die Live-Sendungen gehen sogar 2 mal über den Server, einmal als Einspeisung und einmal das, was an die Hörer ausgeliefert wird.
Insgesamt laufen 6 Mount points über den gleichen Server, davon sind 2 public. Insgesamt sind diverse Ports eingerichtet, die stammen noch aus der Shoutcast Zeit und werden deshalb noch weitergepflegt.

8

Malte,
danke für deine Info.
Ich bin damals nur von Icecast to Shoutcast gewechselt und hatte keine anderen Änderungen vorgenommen und sofort ging die CPU-Last signifikant runter und die Unterbrechungen am Ende eines Liedes waren verschwunden. Ich vermute, dass es zu einem Zeitpunkt war, wo mAirList die neuen Daten zum Server geschickt hat.
Aber ich werde noch einmal Icecast parallel testen um zu sehen ob die Probleme verschwunden sind.
Da ich ausschließlich Windows verwende hilft mir Linux x64 leider nicht. Aber ich habe gestern auch eine x64-Version für Window gefunden.
https://karlheyes.github.io/
Dies ist allerdings nur Version 2.4.0 vom 28.01.2020, ansonsten hat Icecast die Version 2.4.4.
Der Hauptunterschied zwischen x86 und x64 ist wohl 4GB Speichergrenze. Aber ansonsten laufen alle x86 Anwendungen in einem Simulator unter dem x64 Betriebssystem und haben folglich eine schlechterer Performance als x64 Programme.
Werde an dieser Stelle meine weiteren Erfahrungen veröffentlichen.

9

Bislang habe ich keinen mAirList-Zusammenhang gefunden und das mal so laufen lassen, aber mit der Zeit wird das doch ein arg spezifischer Tech-Talk, der mit mAirList nicht mal annähernd was zu tun hat.
Das wäre vermutlich in einem anderen Forum besser aufgehoben. Alternativ diskutiert ihr das auf einem direkten, persönlichen Kommunikationskanal weiter.

Einen echten Mehrwert für die Community kann ich hier ab einem gewissen Punkt nicht mehr erkennen.
Vielen Dank.

10

KH-Icecast ist etwas anderes wie Icecast. Daher auch die Versionsunterschiede.

Und NEIN! 32Bit Anwendungen laufen nicht in einem Simulator und sind dadurch auch nicht in der Performance eingeschränkt. Weder unter Windows noch unter Linux. Wer hat Dir denn diesen Unsinn erzählt? Ganz im Gegenteil, eine 32Bit Anwendung kann unter Umständen auf einem 64Bit OS sogar schneller laufen, weil andere Prozesse besser gehandelt werden und eine optimaler Ressourcenverteilung stattfindet,

Wie sich das auf Windows verhält, mit einem Stream Server weiß ich nicht. Windows hat viel zu viel Overhead, für diese einfache Aufgabe. Mit Linux kam ich hier immer deutlich schneller ans Ziel, ich kenne mich zwar mit Windows gut aus aber Streamserver habe ich da schon ewig nicht mehr eingerichtet. Ich weiß noch das die Installation als Dienst, irgendwie ein Krampf war. Was aber nicht am Streamserver lag sondern an Windows.

11

Es hat nichts mit mAirList zu tun, das stimmt. Aber anderen mAirList Benutzern könnte auch interressieren, da sie ja auch streamen müssen. :thinking:

12

… zum zweiten … :hammer:
(beim Zuschlag packe ich den Schlüssel aus!)

Nicht jeder mAirList-Anwender muss zugleich einen Server aufsetzen und in Betrieb halten. Es handelt sich bei unseren Kunden und Anwendern in aller Regel um Moderatoren und Selbstfahrer.
Dieses Forum ist für die Unterstützung der Anwender dieser Software gedacht.

Für alles weitere empfehle ich tatsächlich ein anderes, besser zum Thema passendes Forum.
Danke.

13

Das greift, mit Verlaub, ein wenig zu kurz. Ein Anwender hat mit der Software nichts zu tun, außer sie zu bedienen, was, einmal sauber aufgesetzt, in der Regel reibungslos vonstatten geht.

Diejenigen aber, die die Software aufsetzen, also konfigurieren, sind es, die hier im Forum sprechen. An die wendet sich der Selbstfahrer, wenn er nicht weiter weiß. Wenn der „Konfigurator“ jedoch Hilfe braucht, wendet er sich hierher.

Geordnete Grüße

TSD

(Was natürlich nichts damit zu tun hat, ob dieser Thread hier nun passend ist oder eben nicht.)