Continuing my
earlier post.
This part of the configuration, for the audio streams, was a series of experiments with Shoutcast v1 and v2 and Icecast2 - from Dec 15 2011 till now. Duplicating our Shoutcast server setup using v1 server as on our earlier server could have been done, but P was keen on improving things, especially the recorded to live (and back) transitions.
Shoutcast2 was our first trial, since using it would help us to restore our multiple streams on
shoutcast.com directory. Tried Shoutcast2's multiple mount strategy. The Shoutcast2 source sc_trans does re-encoding, so we don't want that. Then we found that as
this forum post indicates, sc_serv2 does not work with 1.x source like ices - so we need to have a Shoutcast1 server between ices and Shoutcast2. And when that happens, we can't use many of Shoutcast2's features. Also, if we wanted it running on multiple ports, we would need unique mount points on each port - all the ports show all the mount points. Then came the killer - Shoutcast2 was dumping listeners at live/recorded changeover even with backupfile set, and autodumpusers=0 , when relaying the Shoutcast1 streams. So that ended our Shoutcast2 experiment.
Icecast2 had similar features, like multiple mount points etc. And it was compatible with ices as a source. Only needs a change in the ices config file, instead of icy protocol, it has to use http protocol. And it had the nifty
feature of moving listeners from one mount point to another using the admin interface, which caught P's eye. And fallback mounts, using which
what we wanted to do could be accomplished. Basic idea being:
/mount-to-which-listeners-connect
-has fallback mount-> /livemount
-has fallback mount-> /recordedstream
When fallback override is set to true, whenever a source connects to /livemount, the listeners are automatically moved from /recordedstream to /livemount. And automatically moved back when the source disconnects. Very nice.
But preliminary exploration gave some disappointments - multiple ports still showed up all the mounts on all the ports, and the fallback mounts did not work for shoutcast relays. Also, there were some funny (buggy?) aspects, like mount points with relays not showing up on the admin interface till a (non-relay) source was connected. Also, how to configure the fallback mechanism for TeluguStream was not clear, since we would not be connecting a source to it directly. The fallback update mechanism given in the icecast admin section did not work, since there was no source directly connected to that mountpoint. Finally, cobbled together the following method.
- lots of alias directives, one for each port, redirecting the root / to the correct stream for that port. This could be done because aliases can be defined on a per port basis.
Aliases like alias source="/" port="8008" dest="/discoursestream"
- TeluguStream falls back by default to its recorded stream, and AsiaStream falls back first to the live stream mount, and then to recorded stream - so the live changeover for AsiaStream is taken care of.
- An additional mount was defined as a relay of asiastream, and another icecast config file was written where TeluguStream falls back to this relay instead.
- When TeluguStream has to go live, the icecast config file is switched over, and
killall -HUP icecast makes icecast reload the config file - so, listeners who connect now fall back to the relay of asiastream .
- Using the admin interface, the listeners who were already connected to the recorded telugustream mount are now moved to the relay mount.
- These steps were written into a shell script, with wget being used to do the admin interface calls - wget takes --user= and --password= parameters.
- A shell script which calls the above remote machine's scripts through ssh can be run from the Mac by double-clicking on the file, by just naming the script file with a .command extension.
- For our website's jplayer-based web player to work, had to change the called URL - for shoutcast it was mp3:"http://stream.radiosai.net:8002/;stream/1" and now for icecast it should be mp3:"http://server1.radiosai.org:8002/"
The stream suffix was for Shoutcast to serve the stream instead of the status page. Our aliases are configured to redirect requests from root to the appropriate stream, so we can just request the root, /
- Just a caveat - icecast by default has very small numbers in threadpool and source connections. Have given 50 and 20 for now.
- Made icecast run like a daemon by calling it with nohup:
nohup icecast -c /path/to/icecast_config_file.xml > sh.out 2> sh.err < /dev/null &
Then came the monitoring part. P pointed to
amptracker.com with nice graphs. But they wanted $5 per month for the graphs. So, went back to
shoutstats, which now has support for icecast too. But after install, found it did not work. Troubleshooting:
- First, apache was serving the file index.php like html, without rendering the php parts. Reason was, php short tags were turned off in our server, as found with phpinfo(). Enabled them in /etc/php5/apache2/php.ini
and restarted apache2, the page displayed now. But shoutstats itself was not showing any graphs, even after I updated manually by accessing update.php manually.
- Tested rrdtool with http://oss.oetiker.ch/rrdtool/tut/rrdtutorial.en.html
and working fine.
- Enabling print statements for debugging inside the php pages, found that though rrdtool was being called, it was not creating the .rrd file. File permissions were 777 for the relevant directories. Finally, printing out the exact system() call pointed out the error - there was a missing space after $rddtool in the system call.
' create '.$rddfile.'DS:audience...
should have been
' create '.$rddfile.' '.'DS:audience
Mentioned it in the github page, fixed it, shoutstats working after correct cron job entered.
- Had to remove the hidden status of the mounts - otherwise shoutstats would not work out of the box, would have to change the parsing of status2.xsl. So, made all the mounts visible - hidden = 0.
Most probably this finishes the server configuration posts. Possible tweaks needed for icecast would be to make the logs smaller - maybe - and maybe some tweaking needed for thread management under load and so on.
