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