Shoutcast-Server hängt bei NSV-Streaming

Status
Für weitere Antworten geschlossen.

McBong

Benutzer
Hallo,

ich bin mir nicht wirklich sicher ob es hier rein passt, aber möchte doch gerne mal mein Glück probieren.

Mein Problem handelt sich um folgendes:

Gesendet wird normalerweise ein reines Audiosignal in 128kbps.
Funktioniert super und ohne Probleme.

Dazu möchten wir einen sporadischen Videostream anbieten, entsprechend wenn ein Moderator technisch dafür die Vorraussetzung hat.
Dieses wird entsprechend über einen zweiten Stream gehändelt.

Der Moderator connected auf den Videostream via NSV-Tools, der Stream läuft, alles wunderbar.

Sobald ein Hörer connected hängt dieser Stream allerdings, samt Serverseite entsprechend zum Port. Dies dauert ca. 10 Sekunden, und der Shoutcastserver läuft hervorragend weiter und reagiert auch.

Zur Information: Der Hörer der nun bereits drauf ist, stellt keinerlei Problem fest.

Nun gehts, weiter. Natürlich kommt der nächste der auch den Videostream einschalten möchte. Da macht der Shoutcast Server entsprechend gleiche Mucken, lässt den Hörer drauf, ist aber anschließend bis zu 10sec. quasi nicht erreichbar. Möchte ein weiterer Hörer in dieser Zeit auch einschalten, hat er keine Chance dazu, bis der Server quasi wieder ordnungsgemäß läuft.

Dieses Problem tritt nur bei NSV Streaming auf ..... wenn nur Audio (Mp3) gestreamt wird, ist keinerlei Problem festzustellen.

Hat irgendwer schon einmal das gleiche Problem gehabt oder weiß jemand Rat dazu?

Ich hoffe, dass ich das Problem soweit verständlich niederschreiben konnte.

Mit freundlichen Grüßen,

McBong
 
AW: Shoutcast Server hängt bei NSV Streaming

Da meine Glaskugel heute, vermutlich aufgrund der hohen Temperaturen, ihren Dienst versagt, stelle ich dir eben die folgenden Fragen nach:

Betriebssystem?
Serverversion?
Logfile (Auszuegen)
Config (Auszuegen)


Du hast sicherlich, im Eifer des Gefechts nur ueberlesen, dass das zu solch technischen Fragen dazu gehoert. - Richtig?
 
AW: Shoutcast Server hängt bei NSV Streaming

Man man man ... wie recht du doch hast. Entschuldige bitte die fehlenden Infos. Ach ja, beim dem Wetter ist das kein Wunder, dass die Glaskugel versagt .. lach.

Also zur Ergänzung:

Betriebsystem: Debian
Serverversion: 1.9.9 beta (1.9.8 habe ich auch getestet. Das gleiche Problem.)

Auszug der Logdatei: (Die kurzen Verbindungen kommen zustande, weil ich getestet habe, wann das Problem auftritt.)
In der Log habe ich IP und Name durch "******" ersetzt.

Code:
<08/06/09@22:10:12> [source] connected from 87.189.186.59
<08/06/09@22:10:12> [source] icy-name: ******; icy-genre:
<08/06/09@22:10:12> [source] icy-pub:0 ; icy-br:256 ; icy-url:**********
<08/06/09@22:10:12> [source] icy-irc: ; icy-icq:N/A ; icy-aim:
<08/06/09@22:10:29> [dest: 87.189.186.59] starting stream (UID: 14)[L: 1]{A: Winamp NSV Player/5.12 (ultravox/2.0)/MPEG}(P: 0)
<08/06/09@22:10:47> [dest: 87.189.186.59] connection closed (18 seconds) (UID: 14)[L: 0]{Bytes: 460716}(P: 0)
<08/06/09@22:11:13> [dest: 87.189.186.59] starting stream (UID: 15)[L: 1]{A: WinampMPEG/5.55, Ultravox/2.1}(P: 0)
<08/06/09@22:11:37> [dest: 87.189.186.59] starting stream (UID: 16)[L: 2]{A: WinampMPEG/5.55, Ultravox/2.1}(P: 1)
<08/06/09@22:11:38> [dest: 87.189.186.59] connection closed (24 seconds) (UID: 15)[L: 1]{Bytes: 953376}(P: 0)
<08/06/09@22:11:51> [dest: 87.189.186.59] starting stream (UID: 17)[L: 2]{A: Winamp NSV Player/5.12 (ultravox/2.0)/MPEG}(P: 0)
<08/06/09@22:11:52> [dest: 87.189.186.59] connection closed (15 seconds) (UID: 16)[L: 1]{Bytes: 673316}(P: 1)
<08/06/09@22:12:12> [dest: 87.189.186.59] connection closed (21 seconds) (UID: 17)[L: 0]{Bytes: 855644}(P: 0)
<08/06/09@22:12:15> [dest: 87.189.186.59] starting stream (UID: 18)[L: 1]{A: Winamp NSV Player/5.12 (ultravox/2.0)/MPEG}(P: 0)
<08/06/09@22:12:33> [dest: 87.189.186.59] connection closed (18 seconds) (UID: 18)[L: 0]{Bytes: 780102}(P: 0)
<08/06/09@22:13:03> [dest: 87.189.186.59] starting stream (UID: 19)[L: 1]{A: Winamp NSV Player/5.12 (ultravox/2.0)/MPEG}(P: 0)
<08/06/09@22:13:34> [dest: 87.189.186.59] connection closed (32 seconds) (UID: 19)[L: 0]{Bytes: 1163397}(P: 0)
<08/06/09@22:13:37> [dest: 87.189.186.59] starting stream (UID: 20)[L: 1]{A: Winamp NSV Player/5.12 (ultravox/2.0)/MPEG}(P: 0)
<08/06/09@22:13:45> [dest: 87.189.186.59] connection closed (8 seconds) (UID: 20)[L: 0]{Bytes: 471619}(P: 0)
<08/06/09@22:14:17> [source] source dropped connection. disconnecting.


Auszug der Config: (Passwörter etc. durch "*****" geändert)

Code:
; SHOUTcast Distributed Network Audio Server configuration file
; Copyright (C) 1998-2004 Nullsoft, Inc.
; All Rights Reserved.
; Last modified Mar 17 2004

; If you want to manage multiple configurations, just copy
; this file to another name, and run sc_serv with that name
; such as:
; sc_serv.exe sc_leet.conf

; ***************************
; Required stuff
; ***************************

; MaxUser.  The maximum number of simultaneous listeners allowed.
; Compute a reasonable value for your available upstream bandwidth (i.e. if
; you have 256kbps upload DSL, and want to broadcast at 24kbps, you would
; choose 256kbps/24kbps=10 maximum listeners.)  Setting this value higher
; only wastes RAM and screws up your broadcast when more people connect
; than you can support.
MaxUser=100

; Password.  While SHOUTcast never asks a listener for a password, a 
; password is required to broadcast through the server, and to perform
; administration via the web interface to this server.  This server should
; consist of only letters and numbers, and is the same server your broadcaster
; will need to enter in the SHOUTcast Source Plug-in for Winamp.  THIS VALUE
; CANNOT BE BLANK.
Password=******
; PortBase. This is the IP port number your server will run on.  The
; value, and the value + 1 must be available.  If you get a fatal error when
; the DNAS is setting up a socket on startup, make sure nothing else on the
; machine is running on the same port (telnet localhost portnumber -- if you
; get connection refused then you're clear to use that port).  Ports < 1024 
; may require root privledges on *nix machines.  The default port is 8000.
PortBase=10210

; ***************************
; Optional Parameters
; ***************************

; ***************************
; Logging configuration
; ***************************

; LogFile: file to use for logging. Can be '/dev/null' or 'none'
; or empty to turn off logging. The default is ./sc_serv.log
; on *nix systems or sc_serv_dir\sc_serv.log on win32.
; Note: on win32 systems if no path is specified the location is
; in the same dir as the executable, on *nix systems it is in the
; current directory.
;LogFile=sc_serv.log
LogFile=/home/******/stream/log_sc_serv_video.log

; RealTime displays a status line that is updated every second
; with the latest information on the current stream (*nix and win32 
; console systems only)
RealTime=1

; ScreenLog controls whether logging is printed to the screen or not
; on *nix and win32 console systems. It is useful to disable this when 
; running servers in background without their own terminals. Default is 1
ScreenLog=1

; ShowLastSongs specifies how many songs to list in the /played.html
; page.  The default is 10.  Acceptable entries are 1 to 20.
ShowLastSongs=10

; TchLog decides whether or not the DNAS logfile should track yp 
; directory touches.  Adds and removes still appear regardless of
; this setting.
; Default is yes
; TchLog=yes

; WebLog decides whether or not hits to http:// on this DNAS will
; be logged.  Most people leave this off because the DSP plug-in
; uses http:// calls to update titles and get the listener count,
; which takes up a lot of log space eventually.  If you want to
; see people making hits on your admin.cgi or index pages, turn
; this back on.  Note that this setting does NOT affect XML stats
; counters for hits to http:// pages.
; Default is no.
; WebLog=no

; W3CEnable turns on W3C Logging.  W3C logs contain httpd-like accounts
; of every track played for every listener, including byte counts those listeners
; took.  This data can be parsed with tools like Analog and WebTrends, or given
; to third parties like Arbitron and Measurecast for their reporting systems.
; Default is Yes (enabled).
W3CEnable=Yes

; W3CLog describes the name of the logfile for W3C logging.  Default logfile is
; sc_w3c.log, in the same directory wherever the DNAS gets started from.
W3CLog=sc_w3c.log


; ***************************
; Network configuration
; ***************************

; SrcIP, the interface to listen for source connections on (or to make relay 
; connections on if relaying). Can and usually will be ANY or 127.0.0.1  
; (Making it 127.0.0.1 will keep other machines from being able to
; broadcast using your shoutcast server )
SrcIP=ANY

; DestIP, IP to listen for clients on (and to contact yp.shoutcast.com)
; can and usually will be be ANY. If your machine has multiple IP addresses,
; set this to the one you want it to be accessed by.
DestIP=ANY

; Yport, port to connect to yp.shoutcast.com on. For people behind caching 
; webproxies, change this to the alternate port (666 is what it might be, 
; check www.shoutcast.com if you have problems). Otherwise, leave this at 80.
; We're actively working on re-opening port 666, but as of release the only
; working port is port 80.
Yport=80

; NameLookups.  Specify 1 to perform reverse DNS on connections.
; This option may increase the time it takes to connect to your
; server if your DNS server is slow.  Default is 0 (off). 
NameLookups=0

; RelayPort and RelayServer specify that you want to be a relay server.
; Relay servers act as clients to another server, and rebroadcast.
; Set RelayPort to 0, RelayServer to empty, or just leave these commented
; out to disable relay mode.
; RelayPort=8000
; RelayServer=192.168.1.58

; ***************************
; Server configuration
; ***************************

; AdminPassword.  This password (if specified) changes the
; behavior of Password to be a broadcast-only password, and
; limits HTTP administration tasks to the password specified
; here.  The broadcaster, with the password above, can still
; log in and view connected users, but only the AdminPassword
; will grant the right to kick, ban, and specify reserve hosts.
; The default is undefined (Password allows control for both 
; source and admin)
AdminPassword=*******

; AutoDumpUsers controls whether listeners are disconnected if the source
; stream disconnects. The default is 0.
AutoDumpUsers=0

; AutoDumpSourceTime specifies how long, in seconds, the source stream is
; allowed to be idle before the server disconnects it. 0 will let the source
; stream idle indefinately before disconnecting. The default is 30.
AutoDumpSourceTime=30

; ContentDir specifies the directory location on disk of where to stream
; on-demand content from.  Subdirectories are supported as of DNAS 1.8.2.
; Default is ./content, meaning a directory named content in the same directory
; as where sc_serv was invoked from.
; ContentDir=./content

; IntroFile can specify a mp3 file that will be streamed to listeners right
; when they connect before they hear the live stream.
; Note that the intro file MUST be the same samplerate/channels as the 
; live stream in order for this to work properly. Although bitrate CAN
; vary, you can use '%d' to specify the bitrate in the filename
; (i.e. C:\intro%d.mp3 would be C:\intro64.mp3 if you are casting at 64kbps).
; The default is no IntroFile
; IntroFile=c:\intro%d.mp3

; BackupFile can specify a mp3 file that will be streamed to listeners over
; and over again when the source stream disconnects. AutoDumpUsers must be
; 0 to use this feature. When the source stream reconnects, the listeners
; are rejoined into the live broadcast.
; Note that the backup file MUST be the same samplerate/channels as the 
; live stream in order for this to work properly. Although bitrate CAN
; vary, you can use '%d' to specify the bitrate in the filename
; (i.e. C:\backup%d.mp3 would be C:\backup32.mp3 if you are casting at 32kbps).
; The default is no BackupFile
; BackupFile=C:\intro%d.mp3

; TitleFormat specifies a format string for what title is sent to the listener.
; For example, a string of 'Justin Radio' forces the title 'Justin Radio' even
; when the source changes the title. You can use up to one '%s' in the string
; which lets you contain the title from the source. For example, if your 
; TitleFormat is 'Justin Radio: %s', and the source plug-in's title is 
; 'Billy plays the blues', then the net title is 
; 'Justin Radio: Billy plays the blues'. Note: only works on non-relay servers.
; The default is no format string. 
TitleFormat=%s

; URLFormat specifies a format string for what url is sent to the listener.
; Behaves like TitleFormat (see above).
; The default is no format string.
; URLFormat=http://www.server.com/redirect.cgi?url=%s

; PublicServer can be always, never, or default (the default, heh)
; Any setting other than default will override the public status
; of the source plug-in or of a SHOUTcast server that is being relayed.
PublicServer=never

; AllowRelay determines whether or not other SHOUTcast servers will be
; permitted to relay this server.  The default is Yes.
AllowRelay=Yes

; AllowPublicRelay, when set to No, will tell any relaying servers not
; to list the server in the SHOUTcast directory (non-public), provided
; the relaying server's Public flag is set to default.  The default is
; Yes.
AllowPublicRelay=No

; MetaInterval specifies how often, in bytes, metadata sent.
; You should really leave this at the default of 8192, but the option is 
; provided anyway.
MetaInterval=32768

; *****************************
; Access Control
; *****************************

; ListenerTimer is a value in minutes of maximum permitted time for
; a connected listener.  If someone is connected for longer than this
; amount of time, in minutes, they are disconnected.  When undefined,
; there is no limit defined.  Default is undefined.
; ListenerTimer=600

; BanFile is the text file sc_serv reads and writes to/from
; for the list of clients prohibited to connect to this
; server.  It's automatically generated via the web
; interface.
; BanFile=sc_serv.ban

; RipFile is the text file sc_serv reads and writes to/from
; for the list of client IPs which are *ALWAYS* permitted
; to connect to this server (useful for relay servers).
; This file is automatically generated via the web
; interface.  Note that if your server is FULL, and someone
; from a Reserved IP connects, the DNAS will force the person
; listening for the longest time off to make room for the new
; connection.
; RipFile=sc_serv.rip

; RIPOnly, when set to Yes, will only allow IP addresses listed in the Reserved
; IP list to connect and relay.  All other connections for listening will be denied.
; This is really only useful for servers whose sole purpose is to provide the
; primary feed to all public relays.  Setting this value to Yes also forces the
; server into Private mode, since listing this server in the directory would
; be pointless.  Default is No.
; RIPOnly=No

; *****************************
; Extended Logging 
; *****************************

; The old features previously at this location, HistoryLog and CurrentLog, are
; no longer used and succeded by W3C Logging and XML, respectively.

; ***************************
; Mass Configuration
; ***************************

; Unique: assigns a variable name for use in any config item which points to a
; file.  Useful for servers running lots of SHOUTcast servers that have similar
; configuration parameters, excepting logfile names, banfile names, etc.  Any
; parameter that takes a pathname can include the character $, which will
; substitute $ for the variable assigned here.  Keep in mind that the unique
; variable can only be used after it is defined, so don't try to use a unique
; variable substitution in a path before you define it.  For example, you 
; could set:
; Unique=my_server
; and then define Log=/usr/local/shoutcast/$.log in an included configuration 
; file.  Default is Unique=$, so that by default any file with $ in the name 
; won't substitute anything at all.

; Include: instructs the sc_serv to read from the named configuration file,
; *at the point of insertion of the Include statement*, and process as though
; the included file was part of itself.  Note that all configuration parameters
; in the DNAS config file are processed first to last, so if an item is defined
; twice in a configuration, the last item to process will be the one that takes
; effect.  For this reason, it's usually a good idea to use the Includes first
; in a config file.
; example:
; Include=/usr/local/shoutcast/common.conf
; Default is not applicable.

; *****************************
; Tweaks
; *****************************
;
; DON'T MESS WITH THIS STUFF UNLESS YOU REALLY KNOW WHAT YOU'RE DOING.
; DON'T COMPLAIN TO US IF YOU MESS WITH IT AND THINGS BREAK.
; HAVE A NICE DAY.

; CpuCount is used to explicitly limit the DNAS to dominating a finite
; amount of processors in multiprocessor systems.  By default, 
; SHOUTcast creates one thread for every processor it detects in the
; host system, and assigns listeners equally across all the threads.
; In the event SHOUTcast doesn't correctly determine the number of
; CPUs in your host, or if you for whatever reason want to force
; the DNAS to not use other processors, you can say so here.
; Default behavior is to use as many processors as the DNAS detects on
; your system.
; CpuCount=1

; Sleep defines the granularity of the client threads for sending data.
; DNAS 1.7.0, per client thread, will send up to 1,024 bytes of data
; per socket (or less depending on the window available), and then
; sleep for the provided duration before repeating the whole process.
; Note that making this value smaller will vastly increase CPU usage on 
; your machine.  Increasing reduces CPU, but increasing this value too far 
; will cause skips.  The value which seems most optimal for 128kbps 
; streaming is 833 (833 microseconds per client poll) on our test labs.
; We wouldn't recommend setting it any lower than 100, or any higher than 
; 1,024.  If you have a slower machine, set this number lower to fix
; skips.
; Default value is 833.
; Sleep=833

; CleanXML strips some whitespace and linefeeds from XML output which
; confuses some (poorly written) XML parsers.  If you get XML rendering errors,
; try turning this on.  Default is No (off).
; CleanXML=No
;
; TAG RULES

Leider fällt mir dort nichts besonderes auf.
Der Load des Server liegt absolut im grünen Bereich.

Wie gesagt, Audiostreaming funktioniert super ohne jegliche Probleme, auf dem gleichen Server, gleiche IP usw.
Portwechsel habe ich auch probiert, ändert auch nichts an dem Problem.

Vielen Dank und mit freundlichen Grüßen,

McBong
 
AW: Shoutcast-Server hängt bei NSV-Streaming

Das Problem, das du mit dem streaming hast, scheint mir beim ersten Ueberfliegen der Logfiles mehr an der Bandbreite deines Internetzuganges zu liegen.

Es macht den Anschein, als koenntest du zwar auf den Stream connecten, aber aufgrund zu geringer Bandbreite deines Internetzuganges scheint ein Disconnect vom Server unausweichlich - und damit der Stream wieder abzubrechen.

Begruendung:
Wie du selbst in deinem ersten Posting schriebst, ist es durchaus moeglich, eine Verbindung mit 128kbps herzustellen, 256kbps machen Probleme.

Dazu kommt noch der Download.
Der Server, sowie der PC zuhause antworten jeweils mit kleinen "Paketen", die dem jeweiligen Rechner gegenueber signalisieren, dass der "Stream" noch aktuell ist und das gesendete "Paket" angekommen ist (auch ueber den entsprechenden Zustand wird Auskunft erteilt).
Das kommt ergo noch zum Upstream, also zu den 128/256kbps hinzu. - Dies wird leider nur zu oft vergessen.

Informiere dich, bzw. uns am besten gleich mal, wie hoch der Upstream deines Internetzuganges ist. :)
 
AW: Shoutcast-Server hängt bei NSV-Streaming

Das Problem, das du mit dem streaming hast, scheint mir beim ersten Ueberfliegen der Logfiles mehr an der Bandbreite deines Internetzuganges zu liegen.

Es macht den Anschein, als koenntest du zwar auf den Stream connecten, aber aufgrund zu geringer Bandbreite deines Internetzuganges scheint ein Disconnect vom Server unausweichlich - und damit der Stream wieder abzubrechen.

Begruendung:
Wie du selbst in deinem ersten Posting schriebst, ist es durchaus moeglich, eine Verbindung mit 128kbps herzustellen, 256kbps machen Probleme.

Dazu kommt noch der Download.
Der Server, sowie der PC zuhause antworten jeweils mit kleinen "Paketen", die dem jeweiligen Rechner gegenueber signalisieren, dass der "Stream" noch aktuell ist und das gesendete "Paket" angekommen ist (auch ueber den entsprechenden Zustand wird Auskunft erteilt).
Das kommt ergo noch zum Upstream, also zu den 128/256kbps hinzu. - Dies wird leider nur zu oft vergessen.

Informiere dich, bzw. uns am besten gleich mal, wie hoch der Upstream deines Internetzuganges ist. :)

Hallo Inselkobi,
vielen Dank für deine Antwort.

Leider scheine ich es doch nicht richtig erklärt, du falsch verstanden oder wir
aneinander vorbei geredet zu haben.

Das Problem welches ich beschreibe, ist nicht das, dass ich Probleme habe an sich zu streamen weil meine Internetanbindung nicht aussreicht.
Eine 16.000 Leitung, die von der Telekom bissl runtergeschraubt wurde, dank netten vielen Nachbarn die auch DSL haben wollten, stellt kaum das Problem dar.
Letztlich bleibt mir folgende Leitung: 13250 kBit/s Download / 1083 kBit/s Upload.

Es ist egal, ob ich streame oder ein anderer Kollege. Es ist egal ob ich auf den Videostream (NSV) einschalte oder wer anderes.

Sobald ein Connect (als Hörer) zum Videostream hergestellt wird, hängt der Shoutcast-Server. In dieser Zeit ist die Serverseite (z.B. http://www.dies-ist-meine-ip.de:8000/ ) nicht erreichbar und endet mit einer "Netzwerk-Zeitüberschreitung", bei mir sowohl bei Anderen.

Die Radio Toolbox, wenn dir das was sagt, zeigt in diesem Fall "Checking...", sprich auch diese kann den momentanen Status des ShoutcastServer nicht abrufen.

Um deiner Theorie nochmals nachzukommen, habe ich die NSV Einstellungen reduziert. so dass ich auf 80kbps Video und 48kbps Audio (zusammen 128kbps) gestreamt habe. Auch dort besteht das gleiche Problem.
Es liegt nicht an der Höhe der Bitrate, sondern eben, sobald in NSV gestreamt wird, dass nicht meine Internetanbindung schlapp macht, sondern eben der Shoutcastserver nicht erreichbar ist, für ne kurze Weile.

Ich hoffe, diesmal das Ganze etwas besser erklärt zu haben.
Wenn nicht, bitte Fragen stellen, damit sich das Problem vll. bald mal lösen lässt.

Ein schönes Wochenende
McBong
 
AW: Shoutcast-Server hängt bei NSV-Streaming

Ich geselle mich mal dazu.
Das Problem was hier beschrieben ist kenne ich bei mir ist es das selbe Problem ebenfalls Debian als Beriebsystem und die Server Software ich kann auch ausschließen das es nur an der Version 1.9.9 liebt denn bei der Version 1.9.8 gibt es das selbe Problem.

Hat jemand schon eine Lösung gefunden?


Gruß
sport-bmw
 
AW: Shoutcast-Server hängt bei NSV-Streaming

Überprüfe mal die Konfig von deinen NSV-Tools. Hatte anfangs das selbe problem (Bandbreite!). Habe mir dann über Google die optimalen Einstellungen für eine DSL 1000 Leitung geholt (habe DSL 16.000, habe aber noch andere Sachen laufen im Netzwerk) und schwupp es geht hervorragend. Hat auch den Vorteil, dass es bei fast jedem Zuhörer funktioniert, denn DSL 1000 hat fast jeder.

Die Einstellungen (welche auch ich verwendet habe) bekommst du hier ausführlich beschrieben:
http://www.tutorials.de/forum/sonstige-tutorials/309461-video-streaming-mit-winamp.html

Wenn du das dann alles so eingestellt hast, sollte es auch keine Probleme mehr geben.
 
AW: Shoutcast-Server hängt bei NSV-Streaming

Überprüfe mal die Konfig von deinen NSV-Tools. Hatte anfangs das selbe problem (Bandbreite!). Habe mir dann über Google die optimalen Einstellungen für eine DSL 1000 Leitung geholt (habe DSL 16.000, habe aber noch andere Sachen laufen im Netzwerk) und schwupp es geht hervorragend. Hat auch den Vorteil, dass es bei fast jedem Zuhörer funktioniert, denn DSL 1000 hat fast jeder.

Die Einstellungen (welche auch ich verwendet habe) bekommst du hier ausführlich beschrieben:
http://www.tutorials.de/forum/sonstige-tutorials/309461-video-streaming-mit-winamp.html

Wenn du das dann alles so eingestellt hast, sollte es auch keine Probleme mehr geben.

Jumbo, vielen Dank für deine Hilfe.
Aber wie oben mehrfach beschrieben, besteht das Problem nicht wegen fehlender Bandbreite.


Bis dafür ein Lösungweg gefunden wird, habe ich einen IceCast-Server aufgesetzt. Dort funktioniert das NSV-Streaming problemlos.

Mfg. McBong
 
AW: Shoutcast-Server hängt bei NSV-Streaming

Wieso bleibst du nicht bei einem Icecast, wenn die Loesung doch funktioniert? :rolleyes:
 
AW: Shoutcast-Server hängt bei NSV-Streaming

Wieso bleibst du nicht bei einem Icecast, wenn die Loesung doch funktioniert? :rolleyes:

Hallo Inselkobi, das ist in der Tat eine Überlegung wert, an der ich schon dran bin.

Nur warum alles über Bord werfen, entsprechend auch den Audiostream, wenn es doch letztlich eigentlich auch mit dem Shoutcast funktionieren müsste.

Sicher, du hast Recht, man nehme das, was auch funktioniert, aber letztlich lernt man auch nicht dadurch und ich möchte schon gerne den Grund dafür wissen.


IceCast ist eigentlich eine feine Sache, zumal es dazu auch noch den Shoutcast-Kompatibilitäts-Modus gibt, womit ich nun auch den NSV Stream erfolgreich ohne andere oder weitere Einstellungen getestet habe.

Inselkobi .... Hand aufs Herz ... welchen Server würdest du nutzen?
Abgesehen, dass du sicherlich überhaupt kein NSV nutzen würdest ^^

Gruß McBong
 
AW: Shoutcast-Server hängt bei NSV-Streaming

Ich weiß, welchen Streaming-Server ich einem Talkradio gerade zur Verfuegung stelle ... ;)
Und das ist kein Shoutcast!

Und richtig!
Ich wuerde kein NSV nutzen - und das Talkradio nutzt ebenfalls kein NSV.

Icecast hat nur einige Vorteile gegenueber dem Shoutcast.
Einen nanntest du bereits:
Den Kompatibilitaets-Modus.
Des weiteren bietet Icecast einen sog. "Fallback".
Und noch einige mehr.
Und das alles in einem Server.
Wozu noch mehr installieren? ;)
 
AW: Shoutcast-Server hängt bei NSV-Streaming

Ich weiß, welchen Streaming-Server ich einem Talkradio gerade zur Verfuegung stelle ... ;)
Und das ist kein Shoutcast!

Und richtig!
Ich wuerde kein NSV nutzen - und das Talkradio nutzt ebenfalls kein NSV.

Icecast hat nur einige Vorteile gegenueber dem Shoutcast.
Einen nanntest du bereits:
Den Kompatibilitaets-Modus.
Des weiteren bietet Icecast einen sog. "Fallback".
Und noch einige mehr.
Und das alles in einem Server.
Wozu noch mehr installieren? ;)

Vielen Dank für deine Antwort.

Stimme ich Dir vollkommen zu, dazu kommt noch das mehrere Mountpoints zugleich über lediglich nur einen Server betrieben werden.

Gibt es denn auch Nachteile, die mir nicht ersichtlich sind?

Mfg. McBong
 
AW: Shoutcast-Server hängt bei NSV-Streaming

Gegebenenfalls der, dass der Zugriff fuer Streamripper erschwert wird.
Das liegt an dem vorhandenen Mountpoint.
Außerdem dass, wie du gemerkt haben duerftest, die Konfiguration nicht ganz so einfach ist, wie bei Shoutcast. ;)

Ein weiterer Vorteil an Icecast ist uebrigens, dass er nicht nur MP3 streamen kann, sondern auch weitere Formate, wie .ogg oder dergleichen.

Alles in allem stehen hier m.E. zwei Vorteile einem Nachteil gegenueber.
 
AW: Shoutcast-Server hängt bei NSV-Streaming

Gegebenenfalls der, dass der Zugriff fuer Streamripper erschwert wird.
Das liegt an dem vorhandenen Mountpoint.
Außerdem dass, wie du gemerkt haben duerftest, die Konfiguration nicht ganz so einfach ist, wie bei Shoutcast. ;)

Ein weiterer Vorteil an Icecast ist uebrigens, dass er nicht nur MP3 streamen kann, sondern auch weitere Formate, wie .ogg oder dergleichen.

Alles in allem stehen hier m.E. zwei Vorteile einem Nachteil gegenueber.

Vielen Dank für die schnelle Antwort.

Was die Nachteile angeht, liegt dann noch im Auge des Betrachters.
Eine etwas schwierigere Konfiguration aber sicherlich nicht. Ein Haus ist auch nicht in 5 Minuten erbaut.

Ich werde mir reichlich Gedanken machen, welches evtl. zum Umzug auf IceCast hinauslaufen könnte.

Zum eigentlichen Topic: Ich wäre natürlich weiterhin interessiert wenn da jemand eine Lösung parat hat. Selbst bei einem Wechsel zu IceCast bliebe das Problem noch im Köpfchen, wofür ich dennoch gern den Grund wissen würde.

Ich bin dann mal los zur Arbeit.
Vielen Dank und freundliche Grüße,

McBong
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben