Icecast - May 2010 - Icecast2 Station with multiple scheduled DJs?

I have been playing with Icecast only for a couple of days, and I am trying to
figure out how to do something.

I want a listener to have to only deal with one stream, but I want to be able to
switch the source of that stream between multiple sources (DJs). The core idea
is that the listener only deals with /live.mp3 while in the background I can
problematically switch between a series of live sources (DJs) or an "Auto
DJ Playlist" source - all based on a schedule for 24/7 content. The total
amount of DJs is currently unknown (4+), as this is just the planing stages.

So far I only have two ideas, neither of which seams optimal
1) use the move listener function to constantly shift users around to the
correct DJ stream.
2) use a third party restream program, such as StreamTranscoder or LiquidSoap
3) use 4 dj mount points that fallback to each other and finally to the autoDJ,
and make the DJs pick a stream to take over when their show starts. (this
untested)

(Long discussion on how I don't know how to do that, and ways that I have
tried)

So far I have tried the following (this is on a Debian machine running Icecast
2.3.2, all mounts are 128 kbs mp3, i can try a win32 version of icecast2, but I
assume there should be no functional difference)

*******************************************************************
This was my first setup to familiarize my self with icecast
mount /EDH.mp3 is hidden  and not public - it has a source of Winamp and edcast
playing music from an old windows box I have
mount /live.mp3 has a fallback to /EDH.mp3 with a fallback override of 1

If the listener connects(windows media player on a windows box) to /live.mp3.m3u
they hear the autoDJ until i connect to /live.mp3 with SAM, afterwhich they hear
me, until I disconnect... so far so good

*******************************************************************
Next I tried the following, i wanted to try to swap the listener between two
live sources
mount /dj1.mp3 is playing music from Winamp/edcast on my old windows machine
(classical music)
mount /dj2.mp3 is playing music from Winamp/edcast on a second windows machine
(Ozzy Osborn)
mount /live.mp3 is setup with /dj1.mp3 as the fallback with fallback override
set to 1

When a listener connects (using windows media player on a third windows
machine), they hear dj1
I then, via the web interface
(http://www.icecast.org/docs/icecast-trunk/icecast2_admn.html i.e.
/admin/fallbacks?mount=/live.mp3&fallback=/dj2.mp3 ), change the fallback of
/live.mp3 to /dj2.mp3
the listener still hears dj1 and does not hear dj2.
if i disconnect the listener and re connect, I still heard dj1 and not dj2 even
though when I use /admin/listmounts i see that /dj2.mp3 is listed as the new
fallback.
If i change the /etc/icecast2/icecast.xml to change the fallback there and then
run /etc/init.d/icecast2 reload to reload the config, the listener still hears
dj1, even on a listener reconnect.
I even try a /etc/init.d/icecast2 restart and it does not change. only when I do
a stop/start does any new connections to /live.mp3 switch to dj2

now, I am able to move listeners via the web interface from /live.mp3 to
/dj2.mp3 and they hear dj2. But if i try to move them back to /live.mp3
(thinking that it might then trigger the "new" fallback) they again
hear dj1
With some complicated checking, this might be a solution.

*******************************************************************
Next i tried using two icecast servers
Server A
I remove /live.mp3 from server A, otherwise it is the same server as before
Server B (second Debian box, same subnet as all the machines, otherwise
identical configuration as Server A)
I add a relay called /live.mp3 which is using /dj1.mp3 from Server A as the
source

If a user connects to /live.mp3 they hear dj1
if i change the xml (since there does not seam to be a web interface for editing
relays) to point it to dj2 and do /etc/init.d/icecast2 reload nothing changes.
The listener still hears dj1, even on a listener reconnect. If i do a stop/start
only then does the listener hear the dj2, but it forces a reconnect and
interrupts the user.

*******************************************************************
Finally I tried using a third party program to act as the go between
Server A
(still has /dj1.mp3 and /dj2.mp3 with no change)
Server B
changed /live.mp3 from a relay to a mount with a fallback to /EDH.mp3
added /EDH.mp3 to this server and used a third windows box with Winamp and
edcast to stream)
on server B, I am running streamtranscoder from oddcast to stream /dj1.mp3 to
/live.mp3

when a listener connects to server b /live.mp3 they hear dj1
when i stop the streamsstranscoder and run the one that points to /dj2.mp3 the
user hears the autodj for just a second then they hear dj2
this solution does not actually need two icecast servers, i just had things
setup this way and did not want to move them around just for this test
this solution is re encoding the mp3 stream, which is a loss of quality

*******************************************************************
it looks like my best option might be to have the DJs broadcast in 256kbs mount
points that are hidden, and use liquidsoap to rebroadcast it to the live stream
in 128kbs mp3. I can then control liquidsoap via an external programmatic
interface which allows me to switch from DJ to DJ based on a timer, or to
manually switch to a different show outside of the timer. I just don't like
that it will reencode the audio.

I was planning on using liquidsoap as the final auto dj (winamp/edcast was just
for testing) anyway

Hi,

Le lundi 24 mai 2010 11:10:23, Patrick Bohnet a ?crit :
> it looks like my best option might be to have the DJs broadcast in 256kbs
> mount points that are hidden, and use liquidsoap to rebroadcast it to the
> live stream in 128kbs mp3. I can then control liquidsoap via an external
> programmatic interface which allows me to switch from DJ to DJ based on a
> timer, or to manually switch to a different show outside of the timer. I
> just don't like that it will reencode the audio.
> 
> I was planning on using liquidsoap as the final auto dj (winamp/edcast was
> just for testing) anyway
I'm glad you though about liquidsoap for this application.

One thing that I did not see, though. Liquidsoap can receive the DJ stream 
directly and compose a stream the way you want.

This way, you could compose the stream as you want without having to do 
anything on icecast and the listener side.

In the SVN version you can even connect simultaneously several shoutcast DJs 
by using different ports for each of them..


Romain

On 24 May 2010 12:10, Patrick Bohnet <hquu at yahoo.com>
wrote:
> I have been playing with Icecast only for a couple of days, and I am trying
to figure out how to do something.
> I want a listener to have to only deal with one stream, but I want to be
able to switch the source of that stream between multiple sources (DJs). The
core idea is that the listener only deals with /live.mp3 while in the background
I can problematically switch between a series of live sources (DJs) or an
"Auto DJ Playlist" source - all based on a schedule for 24/7 content.
The total amount of DJs is currently unknown (4+), as this is just the planing
stages.
> So far I only have two ideas, neither of which seams optimal
> 1) use the move listener function to constantly shift users around to the
correct DJ stream.
> 2) use a third party restream program, such as StreamTranscoder or
LiquidSoap
> 3) use 4 dj mount points that fallback to each other and finally to the
autoDJ, and make the DJs pick a stream to take over when their show starts.
(this untested)
You missed the simplest option, which is to set up the 4 (or more)
mount points, and create a symlink to one one of them in a cron job.
This would be by far the lowest overhead...
-Craig

On Tue, 25 May 2010, A. Craig West wrote:
> You missed the simplest option, which is to set up the 4 (or more)
> mount points, and create a symlink to one one of them in a cron job.
> This would be by far the lowest overhead...
I think you are confused.

Icecast mountpoints are virtual, they are not created in the filesystem.

You could achieve the same thing by having a script update the config file 
and adjust the value for an alias.

However this approach might be tricky as it would need to be kept in sync 
with what is actually meant to happen.

The way I dealt with this situation was to have all users connect to the 
same mount point.  Then you can quite easily deal with moving listeners 
around.

I had a structure with prerecorded programs on the main mountpoint, live 
shows on the second and automation on the third, with appropriate 
fallback/fallback-override values.

The only thing about this approach is that listeners will get a few 
seconds of automation between broadcasters.  Oh and you have a shared 
password which may not be ideal.

Geoff.

At WXBH-LP we had a similar need, and we solved it using mpd (music 
player daemon) to coordinate our feed to icecast.

mpd is a music player (supporting playlists, etc.) originally designed 
for local network streaming, but it has several attributes that make it 
suitable for other things:

    * Items in its playlists can be local audio files or remote streams
      (e.g. DJ streams).
    * It can output a stream directly to icecast.
    * As a daemon it can be controlled by various clients including ones
      accessible from the command line, the web, and telnet/ssh. This
      has allowed us to build a scheduling system around it to cause it
      to play particular playlists at their scheduled times.

Each remote DJ must generate his/her own stream to be picked up by mpd. 
We make this easy by defining multiple "remote" streams for their use
on
our icecast server. This has the advantage of letting them connect to 
the remote stream early so they and we can verify that all is well. At 
the scheduled time, that remote stream is then "played" from a
playlist
on mpd.

We are a low-power FM station in the Louisville, Kentucky, area, and we 
are run collectively, so having a distributed architecture (allowing 
remote DJs) is important to us. Our mpd server, icecast server, and 
transmitter are currently in three separate locations. A computer at the 
the transmitter site subscribes to the icecast stream.

Unfortunately, it looks like we will be scrapping this system in a few 
weeks in favor of a proprietary system (SAM Broadcaster) because it 
offers superior sound level compression (i.e. it plays stuff louder) 
which has a direct effect on the strength of our broadcast signal (which 
is important when you are limited to 100 watts).

Until we switch away from mpd, you can learn more at our website, 
http://wxbh.org/OurStationSoftware.html and you can monitor the system's 
operation from http:// studio.wxbh.org/Console.html .

If anyone is interested in what we've done, I'll be happy to tell more 
and share code.

-John Hicks
(For best results in communicating with me directly, substitute my name 
"johnhicks" in place of "johnlist" in my email address.)


On 05/24/2010 12:10 PM, Patrick Bohnet wrote:
> I have been playing with Icecast only for a couple of days, and I am trying
to figure out how to do something.
>
> I want a listener to have to only deal with one stream, but I want to be
able to switch the source of that stream between multiple sources (DJs). The
core idea is that the listener only deals with /live.mp3 while in the background
I can problematically switch between a series of live sources (DJs) or an
"Auto DJ Playlist" source - all based on a schedule for 24/7 content.
The total amount of DJs is currently unknown (4+), as this is just the planing
stages.
>
> So far I only have two ideas, neither of which seams optimal
> 1) use the move listener function to constantly shift users around to the
correct DJ stream.
> 2) use a third party restream program, such as StreamTranscoder or
LiquidSoap
> 3) use 4 dj mount points that fallback to each other and finally to the
autoDJ, and make the DJs pick a stream to take over when their show starts.
(this untested)
>
> (Long discussion on how I don't know how to do that, and ways that I
have tried)
>
> So far I have tried the following (this is on a Debian machine running
Icecast 2.3.2, all mounts are 128 kbs mp3, i can try a win32 version of
icecast2, but I assume there should be no functional difference)
>
> *******************************************************************
> This was my first setup to familiarize my self with icecast
> mount /EDH.mp3 is hidden  and not public - it has a source of Winamp and
edcast playing music from an old windows box I have
> mount /live.mp3 has a fallback to /EDH.mp3 with a fallback override of 1
>
> If the listener connects(windows media player on a windows box) to
/live.mp3.m3u they hear the autoDJ until i connect to /live.mp3 with SAM,
afterwhich they hear me, until I disconnect... so far so good
>
> *******************************************************************
> Next I tried the following, i wanted to try to swap the listener between
two live sources
> mount /dj1.mp3 is playing music from Winamp/edcast on my old windows
machine (classical music)
> mount /dj2.mp3 is playing music from Winamp/edcast on a second windows
machine (Ozzy Osborn)
> mount /live.mp3 is setup with /dj1.mp3 as the fallback with fallback
override set to 1
>
> When a listener connects (using windows media player on a third windows
machine), they hear dj1
> I then, via the web interface
(http://www.icecast.org/docs/icecast-trunk/icecast2_admn.html i.e.
/admin/fallbacks?mount=/live.mp3&fallback=/dj2.mp3 ), change the fallback of
/live.mp3 to /dj2.mp3
> the listener still hears dj1 and does not hear dj2.
> if i disconnect the listener and re connect, I still heard dj1 and not dj2
even though when I use /admin/listmounts i see that /dj2.mp3 is listed as the
new fallback.
> If i change the /etc/icecast2/icecast.xml to change the fallback there and
then run /etc/init.d/icecast2 reload to reload the config, the listener still
hears dj1, even on a listener reconnect.
> I even try a /etc/init.d/icecast2 restart and it does not change. only when
I do a stop/start does any new connections to /live.mp3 switch to dj2
>
> now, I am able to move listeners via the web interface from /live.mp3 to
/dj2.mp3 and they hear dj2. But if i try to move them back to /live.mp3
(thinking that it might then trigger the "new" fallback) they again
hear dj1
> With some complicated checking, this might be a solution.
>
> *******************************************************************
> Next i tried using two icecast servers
> Server A
> I remove /live.mp3 from server A, otherwise it is the same server as before
> Server B (second Debian box, same subnet as all the machines, otherwise
identical configuration as Server A)
> I add a relay called /live.mp3 which is using /dj1.mp3 from Server A as the
source
>
> If a user connects to /live.mp3 they hear dj1
> if i change the xml (since there does not seam to be a web interface for
editing relays) to point it to dj2 and do /etc/init.d/icecast2 reload nothing
changes. The listener still hears dj1, even on a listener reconnect. If i do a
stop/start only then does the listener hear the dj2, but it forces a reconnect
and interrupts the user.
>
> *******************************************************************
> Finally I tried using a third party program to act as the go between
> Server A
> (still has /dj1.mp3 and /dj2.mp3 with no change)
> Server B
> changed /live.mp3 from a relay to a mount with a fallback to /EDH.mp3
> added /EDH.mp3 to this server and used a third windows box with Winamp and
edcast to stream)
> on server B, I am running streamtranscoder from oddcast to stream /dj1.mp3
to /live.mp3
>
> when a listener connects to server b /live.mp3 they hear dj1
> when i stop the streamsstranscoder and run the one that points to /dj2.mp3
the user hears the autodj for just a second then they hear dj2
> this solution does not actually need two icecast servers, i just had things
setup this way and did not want to move them around just for this test
> this solution is re encoding the mp3 stream, which is a loss of quality
>
> *******************************************************************
> it looks like my best option might be to have the DJs broadcast in 256kbs
mount points that are hidden, and use liquidsoap to rebroadcast it to the live
stream in 128kbs mp3. I can then control liquidsoap via an external programmatic
interface which allows me to switch from DJ to DJ based on a timer, or to
manually switch to a different show outside of the timer. I just don't like
that it will reencode the audio.
>
> I was planning on using liquidsoap as the final auto dj (winamp/edcast was
just for testing) anyway
>
>
>
>       
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20100925/11c35d43/attachment-0001.htm

is it free and will it work with my shoutcast server?

On 9/25/10, John List <johnlist at gulfbridge.net>
wrote:
> At WXBH-LP we had a similar need, and we solved it using mpd (music
> player daemon) to coordinate our feed to icecast.
>
> mpd is a music player (supporting playlists, etc.) originally designed
> for local network streaming, but it has several attributes that make it
> suitable for other things:
>
>     * Items in its playlists can be local audio files or remote streams
>       (e.g. DJ streams).
>     * It can output a stream directly to icecast.
>     * As a daemon it can be controlled by various clients including ones
>       accessible from the command line, the web, and telnet/ssh. This
>       has allowed us to build a scheduling system around it to cause it
>       to play particular playlists at their scheduled times.
>
> Each remote DJ must generate his/her own stream to be picked up by mpd.
> We make this easy by defining multiple "remote" streams for their
use on
> our icecast server. This has the advantage of letting them connect to
> the remote stream early so they and we can verify that all is well. At
> the scheduled time, that remote stream is then "played" from a
playlist
> on mpd.
>
> We are a low-power FM station in the Louisville, Kentucky, area, and we
> are run collectively, so having a distributed architecture (allowing
> remote DJs) is important to us. Our mpd server, icecast server, and
> transmitter are currently in three separate locations. A computer at the
> the transmitter site subscribes to the icecast stream.
>
> Unfortunately, it looks like we will be scrapping this system in a few
> weeks in favor of a proprietary system (SAM Broadcaster) because it
> offers superior sound level compression (i.e. it plays stuff louder)
> which has a direct effect on the strength of our broadcast signal (which
> is important when you are limited to 100 watts).
>
> Until we switch away from mpd, you can learn more at our website,
> http://wxbh.org/OurStationSoftware.html and you can monitor the
system's
> operation from http:// studio.wxbh.org/Console.html .
>
> If anyone is interested in what we've done, I'll be happy to tell
more
> and share code.
>
> -John Hicks
> (For best results in communicating with me directly, substitute my name
> "johnhicks" in place of "johnlist" in my email
address.)
>
>
> On 05/24/2010 12:10 PM, Patrick Bohnet wrote:
>> I have been playing with Icecast only for a couple of days, and I am
>> trying to figure out how to do something.
>>
>> I want a listener to have to only deal with one stream, but I want to
be
>> able to switch the source of that stream between multiple sources
(DJs).
>> The core idea is that the listener only deals with /live.mp3 while in
the
>> background I can problematically switch between a series of live
sources
>> (DJs) or an "Auto DJ Playlist" source - all based on a
schedule for 24/7
>> content. The total amount of DJs is currently unknown (4+), as this is
>> just the planing stages.
>>
>> So far I only have two ideas, neither of which seams optimal
>> 1) use the move listener function to constantly shift users around to
the
>> correct DJ stream.
>> 2) use a third party restream program, such as StreamTranscoder or
>> LiquidSoap
>> 3) use 4 dj mount points that fallback to each other and finally to the
>> autoDJ, and make the DJs pick a stream to take over when their show
>> starts. (this untested)
>>
>> (Long discussion on how I don't know how to do that, and ways that
I have
>> tried)
>>
>> So far I have tried the following (this is on a Debian machine running
>> Icecast 2.3.2, all mounts are 128 kbs mp3, i can try a win32 version of
>> icecast2, but I assume there should be no functional difference)
>>
>> *******************************************************************
>> This was my first setup to familiarize my self with icecast
>> mount /EDH.mp3 is hidden  and not public - it has a source of Winamp
and
>> edcast playing music from an old windows box I have
>> mount /live.mp3 has a fallback to /EDH.mp3 with a fallback override of
1
>>
>> If the listener connects(windows media player on a windows box) to
>> /live.mp3.m3u they hear the autoDJ until i connect to /live.mp3 with
SAM,
>> afterwhich they hear me, until I disconnect... so far so good
>>
>> *******************************************************************
>> Next I tried the following, i wanted to try to swap the listener
between
>> two live sources
>> mount /dj1.mp3 is playing music from Winamp/edcast on my old windows
>> machine (classical music)
>> mount /dj2.mp3 is playing music from Winamp/edcast on a second windows
>> machine (Ozzy Osborn)
>> mount /live.mp3 is setup with /dj1.mp3 as the fallback with fallback
>> override set to 1
>>
>> When a listener connects (using windows media player on a third windows
>> machine), they hear dj1
>> I then, via the web interface
>> (http://www.icecast.org/docs/icecast-trunk/icecast2_admn.html i.e.
>> /admin/fallbacks?mount=/live.mp3&fallback=/dj2.mp3 ), change the
fallback
>> of /live.mp3 to /dj2.mp3
>> the listener still hears dj1 and does not hear dj2.
>> if i disconnect the listener and re connect, I still heard dj1 and not
dj2
>> even though when I use /admin/listmounts i see that /dj2.mp3 is listed
as
>> the new fallback.
>> If i change the /etc/icecast2/icecast.xml to change the fallback there
and
>> then run /etc/init.d/icecast2 reload to reload the config, the listener
>> still hears dj1, even on a listener reconnect.
>> I even try a /etc/init.d/icecast2 restart and it does not change. only
>> when I do a stop/start does any new connections to /live.mp3 switch to
dj2
>>
>> now, I am able to move listeners via the web interface from /live.mp3
to
>> /dj2.mp3 and they hear dj2. But if i try to move them back to /live.mp3
>> (thinking that it might then trigger the "new" fallback) they
again hear
>> dj1
>> With some complicated checking, this might be a solution.
>>
>> *******************************************************************
>> Next i tried using two icecast servers
>> Server A
>> I remove /live.mp3 from server A, otherwise it is the same server as
>> before
>> Server B (second Debian box, same subnet as all the machines, otherwise
>> identical configuration as Server A)
>> I add a relay called /live.mp3 which is using /dj1.mp3 from Server A as
>> the source
>>
>> If a user connects to /live.mp3 they hear dj1
>> if i change the xml (since there does not seam to be a web interface
for
>> editing relays) to point it to dj2 and do /etc/init.d/icecast2 reload
>> nothing changes. The listener still hears dj1, even on a listener
>> reconnect. If i do a stop/start only then does the listener hear the
dj2,
>> but it forces a reconnect and interrupts the user.
>>
>> *******************************************************************
>> Finally I tried using a third party program to act as the go between
>> Server A
>> (still has /dj1.mp3 and /dj2.mp3 with no change)
>> Server B
>> changed /live.mp3 from a relay to a mount with a fallback to /EDH.mp3
>> added /EDH.mp3 to this server and used a third windows box with Winamp
and
>> edcast to stream)
>> on server B, I am running streamtranscoder from oddcast to stream
/dj1.mp3
>> to /live.mp3
>>
>> when a listener connects to server b /live.mp3 they hear dj1
>> when i stop the streamsstranscoder and run the one that points to
/dj2.mp3
>> the user hears the autodj for just a second then they hear dj2
>> this solution does not actually need two icecast servers, i just had
>> things setup this way and did not want to move them around just for
this
>> test
>> this solution is re encoding the mp3 stream, which is a loss of quality
>>
>> *******************************************************************
>> it looks like my best option might be to have the DJs broadcast in
256kbs
>> mount points that are hidden, and use liquidsoap to rebroadcast it to
the
>> live stream in 128kbs mp3. I can then control liquidsoap via an
external
>> programmatic interface which allows me to switch from DJ to DJ based on
a
>> timer, or to manually switch to a different show outside of the timer.
I
>> just don't like that it will reencode the audio.
>>
>> I was planning on using liquidsoap as the final auto dj (winamp/edcast
was
>> just for testing) anyway
>>
>>
>>
>>
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
>>
>
>

-- 
Timothy Clark, WTCN Owner and Maniger
 http://wtcnradio.listen2myradio.com
Owner of Timothy Clark Productions
 Want productions work done at low cheap prices, let us know so as we
can take care of you and your needs
 Skypes, djtimothy1 is for personal use

 wtcn.radio for radio station
 timothyclarkofficial for productions bizness

I ended up solving the problem with liquidsoap and two icecast servers.

I have an "internal" icecast server that has 10 mount points... one
for each DJ
with a limit of three listeners on each mount point. A DJ can connect early and 
do sound balancing and checks before hand

I then have a liquidsoap script that listens to each of the 10 internal mount 
points, and rebroadcasts one of them to the external "public" icecast
server
mount point. This switchboard script also has an internal "jukebox"
that it
kicks in when no DJ is playing, or if a DJ drops signal automatically... all 
with out any interuption to the external listener. The switchboard script has a 
bunch of other features, but its main job was to "switch" between the
private
streams based on a file that is changed, and provide backup music if anything 
faltered. The switching of the file was handled by an external php based program
and website, so could be integrated into any solution basically.

it could technically be run from a single ice cast server, or from multiple 
shoutcast servers... the switchboard script did not care... it had N amount of 
sources, a shell script that told it which of the sources was "live",
a backup
smart play list of music if nobody was live or someone dropped, and a target to 
rebroadcast to.

 "Can I burn softly, a silent ember?"
Quu
Patrick Bohnet
Demon Kitty Productions
OtakuVideo




________________________________
From: John List <johnlist at gulfbridge.net>
To: Patrick Bohnet <hquu at yahoo.com>
Cc: icecast at xiph.org
Sent: Sat, September 25, 2010 1:54:34 PM
Subject: Re: [Icecast] Icecast2 Station with multiple scheduled DJs?

 At WXBH-LP we had a similar need, and we solved it using mpd (music player 
daemon) to coordinate our feed to icecast.

mpd is a music player (supporting playlists, etc.) originally designed for local
network streaming, but it has several attributes that make it suitable for other
things:

	* Items in its playlists can be local audio files or remote streams (e.g. DJ 
streams).
	* It can output a stream directly to icecast.
	* As a daemon it can be controlled by various clients including ones accessible
from the command line, the web, and telnet/ssh. This has allowed us to build a 
scheduling system around it to cause it to play particular playlists at their 
scheduled times.

Each remote DJ must generate his/her own stream to be picked up by mpd. We make 
this easy by defining multiple "remote" streams for their use on our
icecast
server. This has the advantage of letting them connect to the remote stream 
early so they and we can verify that all is well. At the scheduled time, that 
remote stream is then "played" from a playlist on mpd.

We are a low-power FM station in the Louisville, Kentucky, area, and we are run 
collectively, so having a distributed architecture (allowing remote DJs) is 
important to us. Our mpd server, icecast server, and transmitter are currently 
in three separate locations. A computer at the the transmitter site subscribes 
to the icecast stream.

Unfortunately, it looks like we will be scrapping this system in a few weeks in 
favor of a proprietary system (SAM Broadcaster) because it offers superior sound
level compression (i.e. it plays stuff louder) which has a direct effect on the 
strength of our broadcast signal (which is important when you are limited to 100
watts).

Until we switch away from mpd, you can learn more at our website, 
http://wxbh.org/OurStationSoftware.html and you can monitor the system's 
operation from http:// studio.wxbh.org/Console.html .  


If anyone is interested in what we've done, I'll be happy to tell more
and share
code. 


-John Hicks
(For best results in communicating with me directly, substitute my name 
"johnhicks" in place of "johnlist" in my email address.)


On 05/24/2010 12:10 PM, Patrick Bohnet wrote: 
I have been playing with Icecast only for a couple of days, and I am trying to 
figure out how to do something.  I want a listener to have to only deal with one
stream, but I want to be able to switch the source of that stream between 
multiple sources (DJs). The core idea is that the listener only deals with 
/live.mp3 while in the background I can problematically switch between a series 
of live sources (DJs) or an "Auto DJ Playlist" source - all based on a
schedule
for 24/7 content. The total amount of DJs is currently unknown (4+), as this is 
just the planing stages.  So far I only have two ideas, neither of which seams 
optimal 1) use the move listener function to constantly shift users around to 
the correct DJ stream. 2) use a third party restream program, such as 
StreamTranscoder or LiquidSoap 3) use 4 dj mount points that fallback to each 
other and finally to the autoDJ, and make the DJs pick a stream to take over 
when their show starts. (this untested)  (Long discussion on how I don't
know
how to do that, and ways that I have tried)  So far I have tried the following 
(this is on a Debian machine running Icecast 2.3.2, all mounts are 128 kbs mp3, 
i can try a win32 version of icecast2, but I assume there should be no 
functional difference)  
******************************************************************* This was my 
first setup to familiarize my self with icecast mount /EDH.mp3 is hidden  and 
not public - it has a source of Winamp and edcast playing music from an old 
windows box I have mount /live.mp3 has a fallback to /EDH.mp3 with a fallback 
override of 1  If the listener connects(windows media player on a windows box) 
to /live.mp3.m3u they hear the autoDJ until i connect to /live.mp3 with SAM, 
afterwhich they hear me, until I disconnect... so far so good  
******************************************************************* Next I tried
the following, i wanted to try to swap the listener between two live sources 
mount /dj1.mp3 is playing music from Winamp/edcast on my old windows machine 
(classical music) mount /dj2.mp3 is playing music from Winamp/edcast on a second
windows machine (Ozzy Osborn) mount /live.mp3 is setup with /dj1.mp3 as the 
fallback with fallback override set to 1  When a listener connects (using 
windows media player on a third windows machine), they hear dj1 I then, via the 
web interface (http://www.icecast.org/docs/icecast-trunk/icecast2_admn.html i.e.
/admin/fallbacks?mount=/live.mp3&fallback=/dj2.mp3 ), change the fallback of
/live.mp3 to /dj2.mp3 the listener still hears dj1 and does not hear dj2. if i 
disconnect the listener and re connect, I still heard dj1 and not dj2 even 
though when I use /admin/listmounts i see that /dj2.mp3 is listed as the new 
fallback. If i change the /etc/icecast2/icecast.xml to change the fallback there
and then run /etc/init.d/icecast2 reload to reload the config, the listener 
still hears dj1, even on a listener reconnect.  I even try a 
/etc/init.d/icecast2 restart and it does not change. only when I do a stop/start
does any new connections to /live.mp3 switch to dj2  now, I am able to move 
listeners via the web interface from /live.mp3 to /dj2.mp3 and they hear dj2. 
But if i try to move them back to /live.mp3 (thinking that it might then trigger
the "new" fallback) they again hear dj1 With some complicated
checking, this
might be a solution.  
******************************************************************* Next i tried
using two icecast servers Server A I remove /live.mp3 from server A, otherwise 
it is the same server as before Server B (second Debian box, same subnet as all 
the machines, otherwise identical configuration as Server A) I add a relay 
called /live.mp3 which is using /dj1.mp3 from Server A as the source  If a user 
connects to /live.mp3 they hear dj1 if i change the xml (since there does not 
seam to be a web interface for editing relays) to point it to dj2 and do 
/etc/init.d/icecast2 reload nothing changes. The listener still hears dj1, even 
on a listener reconnect. If i do a stop/start only then does the listener hear 
the dj2, but it forces a reconnect and interrupts the user.  
******************************************************************* Finally I 
tried using a third party program to act as the go between Server A (still has 
/dj1.mp3 and /dj2.mp3 with no change) Server B changed /live.mp3 from a relay to
a mount with a fallback to /EDH.mp3 added /EDH.mp3 to this server and used a 
third windows box with Winamp and edcast to stream) on server B, I am running 
streamtranscoder from oddcast to stream /dj1.mp3 to /live.mp3  when a listener 
connects to server b /live.mp3 they hear dj1 when i stop the streamsstranscoder 
and run the one that points to /dj2.mp3 the user hears the autodj for just a 
second then they hear dj2 this solution does not actually need two icecast 
servers, i just had things setup this way and did not want to move them around 
just for this test this solution is re encoding the mp3 stream, which is a loss 
of quality  ******************************************************************* 
it looks like my best option might be to have the DJs broadcast in 256kbs mount 
points that are hidden, and use liquidsoap to rebroadcast it to the live stream 
in 128kbs mp3. I can then control liquidsoap via an external programmatic 
interface which allows me to switch from DJ to DJ based on a timer, or to 
manually switch to a different show outside of the timer. I just don't like
that
it will reencode the audio.  I was planning on using liquidsoap as the final 
auto dj (winamp/edcast was just for testing) anyway           
_______________________________________________ Icecast mailing list 
Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast 


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20100925/08bfb1ad/attachment.htm

On Sat, Sep 25, 2010 at 01:54:34PM -0400, John List
wrote:
> We are a low-power FM station in the Louisville, Kentucky, area, and
[snip]
> Unfortunately, it looks like we will be scrapping this system in a
> few weeks in favor of a proprietary system (SAM Broadcaster) because
> it offers superior sound level compression (i.e. it plays stuff
> louder) which has a direct effect on the strength of our broadcast
> signal (which is important when you are limited to 100 watts).
On AM this can be true. On FM, "loudness" gets you no greater received
signal strength, as the amplitude of your signal does not vary, only
its deviation.

If you want greater reach without hiss, go mono. :-)

-- 
Paul Martin <pm at nowster.me.uk>