Category Archives: Shoutcast

Stress testing Shoutcast Server

If you’re like me, you’ve got a shoutcast server configured to handle thousands of connections. I was pretty sure my setup could handle the load, but I wanted to actually find out. After looking around online, I found out an easy way to stress test the server using curl. Here’s a little script I wrote that will allow you to murder your server :D. Run this script on a test machine with a decent internet connection so you can really stress the server. This script should run on basically any linux operating system. I used Ubuntu as my test box.

Just a few things before you run the script.. You will need vnstat (or you’ll have to comment it out) to get the most of the script. Also, be careful with how many threads you run. If your server has the ulimit too low, you could lock up the shoutcast server.

echo "enter a URL to stress test. ex:"
read URL
echo "enter number of threads to run. ex: 50"

for ((N=0; N<$THREADS; N++))
	do  curl -o /dev/null $URL >> /dev/null 2>&1 &
echo "Created "$THREADS" threads connected to "$URL
echo "Live Bandwidth"
echo "hit ctrl-c when you are finished" 
vnstat -l 
echo "Press any button and hit enter to kill all curl processes! Thanks!"
read Q
killall -e curl

If you have any questions please leave a comment below. Thanks

Here’s an example of the script in action.

enter a URL to stress test. ex:
enter number of threads to run. ex: 50
Created 1500 threads connected to
Live Bandwidth
hit ctrl-c when you are finished
Monitoring em0... (press CTRL-C to stop)

 rx: 50.45 Mbit/s 4514 p/s tx: 2.48 Mbit/s 4503 p/s

And bandwidth usage on the server

 rx: 4.14 Mbit/s 7706 p/s tx: 66.88 Mbit/s 8105 p/s

And what Shoutcast looks like with 1500+ connections:

shoutcast stress

There’s a few glitches (backspace might now work when entering stream URL), but I think its a good tool.

Another change in Hosting

All good things must come to an end. After about 18 months of solid performance, I have left for my hosting needs. During that time I uploaded over 83TB of data and had an uptime of 554 days. The server/network were flawless, and it often outperformed servers on other networks in speedtests. I’d recommend to anyone looking for a very solid hosting provider in Europe. I just outgrew the plan I was on.

I have now transitioned all services to an ESXi machine located in Quebec. My host, soyoustart is a “budget” provider for the OVH network. The specs are as follows:

Intel Xeon W3520 (4c/8t) 2.66ghz
32 GB ECC Ram
250mbps connection. (I’ve hit 1000mbps on speedtests though)

This server is running 5-6 mostly Linux virtual machines. I am sharing it with a friend and so far we haven’t really been able to slow it down. We’ve had HD Plex streams, thousands of shoutcast listeners, and VPN connections all going and it just keeps chugging along. We are pleased with the service and expect to stay with them for a while.  I feel like it is much easier to manage multiple services if they’re all on their own VM. Updates/restarts aren’t as painful, and the separation of services allows for more security. I’ll update this post if we have major issues with the service.

More Shoutcast relays have been added

It came to my attention the a few days ago that the online radio station was having some trouble meeting demand for their 24/7 Art Bell streams. I decided to donate 300 slots to them, of which, over 175 have been used during the nights. I hope to continue this service, as there is nothing I enjoy more than a server getting some real-world use!

I did some quick math, and found that at 24kbps (the going rate for Art Bell streams) 300 slots uses around 7200kbps, 7.2mbps, or a little less than 1 megabyte per second (900kb/s). That is really minimal when you look at if from that standpoint. I think that my vps could easily push out around 1.5 mb/s for an extended duration, so I have plenty of capacity. The hardest part is getting the listeners to connect to my server IP and not that of the original streams. It seems that many people are not connecting through services such as shoutcast, but through direct IP address of the streams, which fills up the original server, leaving my relays half-full. Perhaps if I keep the relay going for a good while, the owner of the stream can post the IP address of my server so people can program that address into their IP radios.

It will be interesting to see how my bandwidth usage goes up with the new relays. The first two days are already averaging over 40gb per day. I expect that number to maintain, or even grow in the coming weeks. That would push my monthly usage to over 1.2 TB per month. My plan has a 2TB limit, so that is something to look out for. I don’t expect to break that though, as I am not using the server for much else currently. It would be fun to get a box solely dedicated to relays though, and I might invest in one in the future if listenership continues to climb. I could even see renting out a service for $5 a month for a 100slot relay or something similar to that.

In case any of you are wondering, my host is They are a budget provider, and have mixed reviews online. However, I haven’t really had any complaints about them for VPS hosting, and at the price, they simply CANNOT be beat.  I would recommend them to anybody wanting a low-cost, non mission-critical VPS host to play around with. Their network is Burstnet (so I’ve heard), but it is reliable enough for my needs.

Bandwidth usage on my VPS. It shows how much my network traffic increased with U7Radio’s listeners.

How to configure a shoutcast relay server in ubuntu

So you want to relay your favorite shoutcast stream with your ubuntu VPS, but don’t know where to start? Here’s a quick guide to relaying DNAS v1.9.8 shoutcast server streams.

Step 1: Download the sc_serv_1.9.8 file from this thread, or from another website (afterdawn,, etc)


Step 2: Unzip the .zip and .tar, and FTP them to your server. I use /var/shoutcast for my folder root, but that might not be the most secure. You could use /home/shoutcast or anything really.

Step 3: If you are going to run the server as root (not recommended) you can skip this. Otherwise, make an account (ex. shoutcast) and place the files into a folder in their home.

Step 4: Edit the sc_serv.conf using nano or vi. Edit any and all settings that you find fit. Here is what I have mine set as.


; 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.

; 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

; 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.

; ***************************
; 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.

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

; 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

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

; 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).

; 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.

; ***************************
; 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
; (Making it will keep other machines from being able to
; broadcast using your shoutcast server )

; DestIP, IP to listen for clients on (and to contact
; 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.

; Yport, port to connect to on. For people behind caching
; webproxies, change this to the alternate port (666 is what it might be,
; check 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.

; 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).

; 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.

; ***************************
; 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.

; 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.

; 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=Justin Radio: %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=

; 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.

; AllowRelay determines whether or not other SHOUTcast servers will be
; permitted to relay this server.  The default is 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.

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


The main things that I changed were maxlisteners (set to 100), the passwords, and the relay information.

For the relay, you need the port of the stream, as well as the address. To find this information you must open the listen.pls and find the data in there.

*If you are going to run more than 1 server at a time, you will need to change the portbase. I run my streams at 8100 and 8200.

Step 5:

Now that you have configured your server, ssh in and cd to the appropriate folder. To start the server type

./sc_serv sc_serv.conf

It will now start!

If all goes well, the server will pick up the stream, and start relaying. Shoucast will do some magic, and you will soon be taking some of the load off of the main stream and onto yours. Contact the stream owner ahead of time so you can coordinate reserved slots in their streams.

If you have any questions, please leave them below. Remember, this only works with version 1.9.8!