[icecast-dev] Stream metadata settings

[Melanie]

On 2003.11.30 06:07 oddsock wrote:
>> > - time limited access to streams
>> 
>> This might be useful, a patch would be welcome.
> 
> I guess it would depend on how it was implemented...to me it doesn't seem 
> useful for 99% of the icecast users out there (I could be wrong), I think 
> the implementation or net effect becomes pretty complicated, sure you can 
> dump a listener after a configurable amount of time, but if you want to 
> prevent them from reconnecting, then you are talking some more 
> significant logic...

No the implementation is pretty straightforward, it allows for a time 
window (from-to) which may span 0:00h, the stream is only usable within 
this timewindow. Outside of it, the connect from a source is refused with a 
"temporarily unavailable" code.

When people run icecast without registering their server and paying the 
piper, they're actually committing a copyright infringement when they 
stream music.
We have registered our server and that actually makes all meterial played 
through it legal. Even if the .mp3 base material was downloaded from a 
filesharing system to start with, it would be illegal to listen to it 
privately, but legal to broadcast - a confusing situation. But, we've been 
limited to broadcast no more than 12 hours per day and are required to 
enforce that by technical means. This is the real-world need for the time 
limit.

>> > - streams that can be used by sources, but not by listeners, but can be
>> > fallbacks
>> 
>> This is problematic. What constitutes a 'source' as opposed to a 
>> 'listener'
>> from the point of view of the protocol? Currently, nothing.
>> 
>> Sufficiently generalised, this might be acceptable, though (for example,
>> configurable bans on sources based on various headers, for this 
>> particular
>> case you might match on the user-agent header).
>> 
>> How is this implemented in your patches?
> 
> again, I don't really see the usefulness here in general...I can see how 
> it may be needed by your situation...but not in the general case...I 
> could be wrong though..

We run a multilevel fallback system like this:

/mainstream.ogg   <-- our radio stream, time-limited, this is where 
listeners connect
/always.ogg       <-- a non time-limited stream that allows for specials 
ouside the time window
/playground.ogg   <-- a stream that candidates for our radio group can send 
on, it can be overridden by connecting to a stream above, giving us the 
ability to preempt transmission of racist or terrorist broadcasts. Since 
that stream could be abused by connecting to it as a source, then telling 
your friends to listen to it, communicating the URL via IRC, it is 
"sources-only", it can be listened to only by connecting to the mainstream 
when all higher level streams are idle, but not by connecting directly to 
/playground.ogg.
/auto.ogg         <-- this one runs automatic programming which will kick 
in when no one uses a highr level stream.
/fallback.ogg     <-- this streams runs the station jingle, it's the last 
line of defense against silence.

All but the top-level stream are "sources only", cannot be connected to 
directly by clients. This way, the hierarchy cannot be subverted and 
right-wingers and such cannot abuse the lower level streams. Remember, we 
freely give out the source password to /playground.ogg to all comers..!

The patch is the answer to a real-life situation we were faced with when a 
stream was hijacked some weeks back.

> 
>> > - multilevel fallback and recovery
>> 
>> This is (conceptually, I'm not certain about the actual implementation, I
>> haven't looked at it in sufficient detail) an excellent addition. 
>> Definately
>> welcome.
> 
> yes, this one is definitely needed.. If we can get a patch for only this 
> part then we would seriously look at adopting it...
> 

This was the first patch, it only made most of the others possible. We 
wanted it because sources connect and disconnect frequently, taking turns 
every two hours. That caused the loss of all listener connections, 40% 
didn't return.

>> > - overrides for any metadata and yp flag in the server's config file
>> 
>> Yes, this fits in well with the <mount> section in the config - 
>> per-mountpoint
>> configurable overrides.
> 
> in my opinion, adding new "controls" like this has limited applicability 
> in the general case...I would be more inclined to implement this if more 
> people stood up and said.. "Yeah! I need that..."
> 

This is also a legal issue. We are required to publish a certain station 
name. We cannot let the source control this, because many senders have 
proven to be unreliable. But, we would be liable if we permitted that, it 
may cost us our license.

>> > - ability to exclude local (127.0.0.1) listeners from the statistics
>> 
>> I'm much less sure about this one. The statistics are meant to be 
>> complete. It
>> would seem more sensible to post-process your logs to remove things 
>> you're
>> not interested in. You'll need a stronger justification for this.
> 
> I agree with Mike....Statistics should be complete...it's pretty trivial 
> to do the exclusion you are talking about in the XML parser that is 
> interpreting the stats...
> 

Well, I've tried to fiddle with the xsl stuff, but could not find a 
solution to reliably exclude 127.0.0.1 listeners from the listing. If there 
was a way and someone could point it out, that part of the patch would be 
redundant and obsolete.

Melanie
--- >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-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.