Icecast - Aug 2004 - Suggestion: The ability to limit the number of ICY connections

Hi all:

I'm looking at some of the features in SVN Icecast, particularly the
ability to reclaim fallbacks.  This feature would be very useful for a
project I work with, and could see us switching to icecast from Shoutcast
compatible technology.

One problem arises, however.  Some of our broadcasters use the legacy
Shoutcast DSP plugin, which can only perform ICY-style connects.  My
problem arises from the fact that icecast will automatically create a new
mount point for every concurrent ICY connection received.

This has two side effects.  Firstly, it means that an ICY source is always
allowed to conect, unlike those using the icecast 2 standard who obviously
can't if a given mountpoint is already in use.  Secondly, and more
importantly for me, it means that I cannot be certain that the current
broadcaster is on /ICY_0 or whatever the mount is called.  This makes it
very difficult to program fallbacks and aliases so that listeners hear the
right person.

My solution to this would be limiting the number of ICY connections that
would be accepted.  If I could limit it to 1, for example, I could be sure
that any ICY broadcaster would always appear on ICY_0 and could configure
the server accordingly.

This of course would be configurable and would be off by default.

Thoughts?

Geoff.

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Fri, 21 May 2004, Jack Moffitt wrote:
> Maybe this is a stupid question, but why don't you just use
Oddsock's
> plugins which support the better protocol?
Not a stupid question.  There's three considerations.

1.  This project has around fifty broadcasters.  It has been running for
3.5 years, and whilst some have moved to using plugins like SAM which
(presumably) does support the icecast 2 protocol and a few of us use Linux,
many still use the Shoutcast DSP.  Changing all these people across will
not be an easy process.  Plus, quite a number use OTS DJ to broadcast with,
and I'm at least not aware of any instructions on how to get it to play
ball with Odcast (though the list of changes on the site certainly suggests
it can be done).

2.  This is a project where all the broadcasters, myself included, are
blind.  Last time I tried it, and admittedly it was a long time ago,
Oddcast presented some issues with regard to screen reader accessibility.
I should really run it up the stick again to see what it's like nowadays.

3.  Quite a lot of our broadcasters are very fond of the FHG encoder.  At
least for now, we broadcast at 56kbps 22050Hz stereo, and whilst LAME has
made some great strides at this bitrate in recent times (I use it myself
under Linux and am quite happy with it), the FHG encoder does sound good at
this rate and I know some would be loathed to give it up.  At least as far
as I'm aware, there's no way for Oddcast to make use of Windows codecs,
so
it'd presumably be LAME or nothing.

With regard to this last point, one of the things we're looking at is
changing to Ogg Vorbis, which would solve most of this (point 2 would still
be valid, however).  Our main problem is that we are a project of a
non-profit organisation and have limited resources.  We support our
broadband MP3 listeners through a server relay provided by Nullsoft, so
unless we could find a low-cost or free provider of bandwidth for our
broadband stream, I'd think it unlikely that we'd be able to change.

Anyone interested in the project can visit http://interactive.acbradio.org

Anyway, all of this aside, Icecast does offer backward compatibility with
the shoutcast technology and I would think this feature would help those in
a position of having to stick with an ICY source.

Geoff.

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> One problem arises, however.  Some of our broadcasters use the legacy
> Shoutcast DSP plugin, which can only perform ICY-style connects.  My
> problem arises from the fact that icecast will automatically create a new
> mount point for every concurrent ICY connection received.
Maybe this is a stupid question, but why don't you just use Oddsock's
plugins which support the better protocol?

jack.
--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.