[icecast-dev] Stream metadata settings

[Melanie]

Hi,

in another thread I noticed mention of something that should be controlled 
by the sender. I don't recall what that was, but it struck a wrong note 
with me.

I have made some patches that allow the server configuration to override 
the metadata information the sender specifies, as well as the public flag.

Our environment consists of a radio server that is duly licensed for 
broadcasting music. We have a group of senders using various configuration 
both on Windows and Linux.
For legal as well as "Corporate identity" reasons, we cannot allow the 
sender to set the stream title, genre, description, or make it non-public.
We need to be able to configure all these things on the server in such a 
way that users cannot change them.

It appears that the main thrust of development is in the direction of 
empowering the sender to control all aspects of the transmission, in our 
case that would not be appropriate. Some of the people are barely capable 
of launching the applications, which have benn configured for them by us, 
the core radio team. It's about music, not computers, for many of us. 
Setting such parameters is beyond many. Getting them right each time we 
need to change them is even less practcable.

I believe the server should provide for both sender controlled metadata and 
server controlled metadata. Which of them would actually be used is under 
the server's control, so that users don't have to bother with computer 
settings, but can work on their shows instead.

My newest series of patches provides the following:

- time limited access to streams
- streams that can be used by souces, but not by listeners, but can be 
fallbacks
- multilevel fallback and recovery
- overrides for any metadata and yp flag in the server's config file
- ability to exclude local (127.0.0.1) listeners from the statistics

The first option is a legal requirement in Germany, we cannot broadcast 
24/7 and are required to enforce that by technical means.
The second option's point is to prevent people to connect to a fallback 
stream directly, so fallbacks cannot be used by pirates to broadcast their 
own programming.
Multilevel fallback you already have seen from me, but I've worked out some 
of the bugs since then.
Overrides I explained above - we must be able to make sure that our station 
name appears at all times, also a legal requirement.
Local listeners is what we have because we reencode the streams to 
different formats and bitrates on the server. Our senders don't have the 
bandwidth to feed more than a single stream reliably, we wanted to be able 
to offer our programming in different formats and bitrates simultaneuosly, 
so we need to hook into the main feed and reencode for the other feeds. 
OTOH, we didn't want these system internal "taps" to be counted as 
listeners.

Well, nevermind the patch as such, what do you think about the concepts? 
WHat about the abilities needed to meet the legal requirements? Can thing 
like that go into icecast, or do I simply maintain my private patches?

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.