Geoff Shang
2004-Aug-06 14:23 UTC
[icecast] 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.
Geoff Shang
2004-Aug-06 14:23 UTC
[icecast] Suggestion: The ability to limit the number of ICY connections
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.
Jack Moffitt
2004-Aug-06 14:23 UTC
[icecast] Suggestion: The ability to limit the number of ICY connections
> 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.