Icecast Streaming Media Server

[DJ-Zath]

hi everyone (karl)

I got a simple question:

Is it possable for Icecast to have multiple passwords on a single shoutcast-configured mount??

-DjZ-

[karlH]

only in my branch work. You can use auth url stream auth setting to send those details to a backend system to authenticate. I suppose it could be possible to implement a htpasswd as well but that hasn't been implemented yet. The trunk work does not yet pass shoutcast auth via that mechanism yet

karl.

[DJ-Zath]

Hi Karl!

you know, I owe you, not a beer, but the whole brewery!

In reading your response, I think you might have misunderstood me- mainly my fault for not being clear..

I apologise...

I should have explained that the multiple passwords for for DJs- to share a single mount..

I have ran into a case where a disgruntled DJ was interfereing with other DJs on the system- he was thrown off for playing "inappropiate programming" (neo nazi stuff) but still had the login password- so he was able to "disrupt" other DJs' programs...

This was a different time and a different server (years ago) I have sinced used steamcast and Streamroller streaming servers to combat this situation. Streamroller allowed multiple passwords- and with them being added to an external list/file, password minpolation was simple and straightforeward... didn't even require the server to be reset..a DJ can be dissallowed access on the fly..

if all else fails, I suppose I can put Streamroller in as a "front end" but that would a dirty way of doing things and add unnessessary lag to the streams... I'd rather do this properly, if Icecast can support the option.

Which brings me to the next Q.. listener allowance or rather- disallowance, now this one is closer to your initial reply (I think) but in this case, however, what I need is:

1. disallow all listeners to a mount EXCEPT a specific receiver, the "catch22" is this receiver is hardware-based and does not, nor, can not support http-auth.. IP-based would be acceptable (and probably preferred)

2. this mount will be used as a "fall-back", in which case, then EVERYONE shoud be able to receive it EXCEPT on its own mount/address.. in other words "mentioned above" STILL applies, but the fallback mount can "override" this for itself...

why all this? mainly, I have 2 mounts- ones a "DJ input" mount while the other is a "master broadcast" mount DJs that log into the DJ input via Shoutcast are received via a hardware-based receiver in a rack of equipment- which then route that audio to a master console whenre local programming and advanced processing take place.. from there, its returned to Icecast via a hardware encoder- where its presented to the listeners. the "fallback" is needed in case the master studio loses net-connection and thus keeping the station on the air in the event a DJ is on the input mount while the net-disconnection occurs (its a failsafe).

what do you think? clever?

-DjZ-

[karlH]

The listener add and stream auth settings are used for different connections, former is for listeners, latter is for source connections.

1 The criteria for allowing connections using listener add can use whatever details are available to you, including the ip address.

2. having a fallback is fine but if you want to override but keep the "catch 22" where it is then you have to keep them separate, a local relay (even on-demand) could be used for that. ie fallback to the local relay where that relays the catch-22 authed mountpoint.

karl.

[DJ-Zath]