[Icecast] Shoutcast directory listing?

Tue Aug 9 17:28:06 UTC 2011

My experience with such things leads me to believe that this current 
domination of shoutcast is temporary. It reminds me of the yahoo! 
directories and the struggle to get listed prior to Google. Whether it 
is temporary or not, it is a real concern of anyone implementing a 
server with Icecast. I hope the moderators of this list will allow the 
community to discuss the issue, but if it is too spicy, I don't mind 
moving the discussion a rogue list.

(I don't agree that it is viable to ignore mp3. My decision has been to 
ignore ogg/vorbis for now, because my radio station uses feeds from many 
sources, almost all of which are mp3. Only one feed I have found is 
.aac, and none are .ogg. In my attempts to convert mp3 to ogg, I have 
not found a reliable solution yet. Plus, this is guaranteed to be worse 
than just transmitting the mp3 directly, since both formats are lossy. I 
have been told that it is smart to convert mp3 to ogg but that just 
sounds silly to me.)

The shoutcast directory issue is a real issue for any icecast user that 
wants to promote their streams on various directories, including the 
shoutcast directory.

As background, I use a fairly extensive perl script that feeds mp3 
content to ices0.4 and to icecast2.3.2. The script runs on the server 
but I also want to support live feeds on a separate mount point. 
(http://www.AirProgressive.org)

I see five options (please correct my thinking on these -- I haven't 
tried them all):

1) emulate the interaction with shoutcast both when streaming and with 
YP interaction to fool it into thinking that an shoutcast server is 
talking to it. (Q: does a stream look identical from icecast as from sc? 
If you have any information on this or want to discuss it further 
separate from xiph.org, please contact me directly.)

2) install shoutcast server and relay from icecast to sc_serv. Thus 
streaming is through shoutcast but YP interaction is still (from what I 
have extracted from the documentation) with the source of the relay, and 
thus the icecast server would need to emulate the sc YP protocol as in 
option 1.

3) install shoutcast server and sc_trans and use the new calendar.xml 
setup to accept a relay stream from icecast and feed it through sc_trans 
and sc_serv. That "should" eliminate both the streaming interaction and 
YP interaction from any need for emulation and be in complete compliance 
with any expectations of nullsoft.

4) establish a scripting wrapper that will allow a single script to be 
callable from both icecast and shoutcast. The main difference here (if 
using perl) is that icecast "use"es the perl module, gracefully calling 
the initialization and shutdown procedures, maintaining data in memory 
between calls, etc. while shoutcast simply calls a command-line script 
and expects a list of tracks as STDOUT. The wrapper would wind up 
calling a script the way sc does, so no program state can be stored in 
memory, which is now possible with icecast. Other entry points of the 
API would be to move to the next track, restart, etc. I already had to 
implement a number of watchdogs to keep track of the processes and 
restart them if there were any glitches.

Certainly, option 4 does not violate any expectations of nullsoft, 
because it means we have to run the entire shoutcast server and sc_trans 
in parallel with the icecast server, so they should be happy. The 
downside to this option is I don't know how to deal with live-feeds 
going to two servers at the same time.

5) perform all the work as #4 and move the script to shoutcast as the 
primary server and use icecast only as a relay server. I think this may 
eliminate the troublesome live feed issue, complies with nullsoft 
expectations.

As a side comment, I notice there is no common use of RSS 2.0 to 
describe the radio station content. Since RSS 2.0 commonly describes 
static documents or media, It would require a "best practices" standard 
to be written to say exactly how a given radio station would describe 
itself. This would be a viable project for xiph.org, and the result 
would be that any radio station could describe itself and be aggregated 
into directories without the proprietary hooks that are currently being 
utilized. A source to the server would update the RSS page each time a 
track was changed and number of listeners changed. (Drawback would be 
that it would be easier for station owners to inflate the number of 
listeners.)

-- Ray Lutz

On 8/9/2011 1:44 AM, Thomas.Rucker at tieto.com wrote:
> I hear rumours that it's not too hard.
> There was implicit discussion.
>
> STILL we can not encourage that people violate the express rules of Nullsoft.
> This would make the Icecast project look bad.
>
> Besides we encourage to use ogg/vorbis for streaming and there the situation
> is constantly improving. I think even streaming to Android devices should
> work now (someone please confirm on latest version). Firefox already
> supports it (including the mobile browser Fennec AFAICT) and Mozilla is slowly
> crawling closer to finalizing chaining support. There are flash objects that
> allow playback of ogg/vorbis streaming.
>
> Using ogg/vorbis for streaming is viable.
> It takes us and you to tell that to the potential streaming services that
> they don't have to use mp3 for everything. How would they else know?
>
> My 0,02€
>
> Thomas
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

-- 
---------------------------------------
Raymond Lutz
Cognisys, Inc.
1010 Old Chase Ave., Bldg B
El Cajon (San Diego Cty), CA 92020 USA
Voice 619-447-3246
http//www.cognisys.com