[Icecast] Icecast2 Station with multiple scheduled DJs?

Sun Sep 26 01:16:58 UTC 2010

On 09/25/2010 04:31 PM, Timothy Clark wrote:
> is it free and will it work with my shoutcast server?
>   
Yes, mpd is open source. See http://mpd.wikia.com/ It comes with the 
Ubuntu distribution (although I compiled ours from source in order to 
configure it to stream in mp3 format).

And yes, it can feed a shoutcast server. See 
http://mpd.wikia.com/wiki/Configuration#IceCast

-John

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20100925/533bef19/attachment.htm>