a shoutcast server. Various posts say that you must start with shoutcast
server and use icecast as the relay. (I don't want to do this because we
already have a perl script written to work with ices and I don't want to
have to redo it to work with shoutcast. It looks feasible but will still
be quite a bit of work because there is no state saved between calls
from shoutcast. In ices, all program state can be maintained in memory.)
The reason I am opening up this issue again is because it appears that
shoutcast has introduced a relay mechanism in their calendaring facility
(see http://www.shoutcast2.com/stream/sc_trans/)
- A new type of event as been added to the calendaring system that
allows you to relay other stations. (see calendarxml.txt for more
information)
in calendarxml.txt it says:
3.3 Relay Events
------------------
This allows you to make use of the relaying support within sc_trans
and so when used in
the event system will allow you to control when a relay is allowed
to connect to you
sc_trans instance (much like the DJ support mentioned earlier).
The parameters supported for this event type are:
url : Specify the url of the source to be relayed.
priority : Specify the priority of the source when a relay event
overlaps with that of
another relay event. The result in this case is that the
relay event with the
highest priority will become active.
Note: Supported priority values are 1 (default) and higher.
e.g. This would enable the relaying of the stream on 'my_site' on
port 9000
<relay url="http://my_site:9000" priority="1"/>
Note: It may be necessary to append /; onto the end of the url as in
some cases the wrong
mime type will be returned from the server and so causes the
relay url fail to be
recognised by sc_trans. This depends on the server.
What is wrong with this scenario.
1. Currently running icecast server 2.3.2 and ices0.4 using mp3
(32kbps/22050Hz) and custom perl script to serve up the content.
(AirProgressive.org).
2. Install shoutcast dnas and sc_trans
3. use calendaring system to add a relay from icecast,
<relay url="http://airprogressive.org:8000/stream"
priority="1"/>
Anyone tried this yet?
From just reading it, it seems like it might work, but I am worried
that relaying the listening stream is not the right way to go. Is there
some reason it is not feasible to relay the same stream that would be
sent to a listener?
THANKS!
--Ray
--
---------------------------------------
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
--------------060406040502020702030206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I've been reading posts on the difficulty in getting an icecast
stream listed in the shoutcast directory. Apparently, it is
necessary to run the shoutcast server to do this. Before I go down a
cheeseless rathole, I thought I'd pass this over this list to see
what response I would get. From what I have read, it is not possible
to relay an icecast stream to a shoutcast server. Various posts say
that you must start with shoutcast server and use icecast as the
relay. (I don't want to do this because we already have a perl
script written to work with ices and I don't want to have to redo it
to work with shoutcast. It looks feasible but will still be quite a
bit of work because there is no state saved between calls from
shoutcast. In ices, all program state can be maintained in
memory.)<br>
<br>
The reason I am opening up this issue again is because it appears
that shoutcast has introduced a relay mechanism in their calendaring
facility (see <a class="moz-txt-link-freetext"
href="http://www.shoutcast2.com/stream/sc_trans/">http://www.shoutcast2.com/stream/sc_trans/</a>)<br>
<br>
<blockquote>- A new type of event as been added to the calendaring
system that allows you to relay other stations. (see
calendarxml.txt for more information)<br>
<br>
</blockquote>
in calendarxml.txt it says:<br>
<blockquote>3.3 Relay Events<br>
------------------<br>
<br>
This allows you to make use of the relaying support within
sc_trans and so when used in<br>
the event system will allow you to control when a relay is allowed
to connect to you<br>
sc_trans instance (much like the DJ support mentioned earlier).<br>
<br>
<br>
The parameters supported for this event type are:<br>
<br>
url : Specify the url of the source to be relayed.<br>
<br>
priority : Specify the priority of the source when a relay event
overlaps with that of<br>
another relay event. The result in this case is that
the relay event with the<br>
highest priority will become active.<br>
<br>
Note: Supported priority values are 1 (default) and
higher.<br>
<br>
<br>
e.g. This would enable the relaying of the stream on 'my_site' on
port 9000<br>
<br>
<relay url=<a
class="moz-txt-link-rfc2396E"
href="http://my_site:9000">"http://my_site:9000"</a>
priority="1"/><br>
<br>
Note: It may be necessary to append /; onto the end of the url as
in some cases the wrong<br>
mime type will be
returned from the server and so causes the
relay url fail to be<br>
recognised by sc_trans.
This depends on the server.<br>
</blockquote>
<br>
What is wrong with this scenario.<br>
1. Currently running icecast server 2.3.2 and ices0.4 using mp3
(32kbps/22050Hz) and custom perl script to serve up the content.
(AirProgressive.org).<br>
2. Install shoutcast dnas and sc_trans<br>
3. use calendaring system to add a relay from icecast,<br>
<relay
url=<a class="moz-txt-link-rfc2396E"
href="http://airprogressive.org:8000/stream">"http://airprogressive.org:8000/stream"</a>
priority="1"/><br>
<br>
Anyone tried this yet?<br>
From just reading it, it seems like it might work, but I am worried
that relaying the listening stream is not the right way to go. Is
there some reason it is not feasible to relay the same stream that
would be sent to a listener?<br>
<br>
THANKS!<br>
<br>
--Ray <br>
<pre class="moz-signature" cols="72">--
---------------------------------------
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</pre>
</body>
</html>
--------------060406040502020702030206--
