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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> My newest series of patches provides the following: > > - time limited access to streamsThis might be useful, a patch would be welcome.> - streams that can be used by souces, but not by listeners, but can be > fallbacksThis 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?> - multilevel fallback and recoveryThis is (conceptually, I'm not certain about the actual implementation, I haven't looked at it in sufficient detail) an excellent addition. Definately welcome.> - overrides for any metadata and yp flag in the server's config fileYes, this fits in well with the <mount> section in the config - per-mountpoint configurable overrides.> - ability to exclude local (127.0.0.1) listeners from the statisticsI'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. <p>Mike --- >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.
to add to Mike's comments.... At 11:42 AM 11/27/2003 +1100, you wrote:> > My newest series of patches provides the following: > > > > - 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...> > - streams that can be used by souces, 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..> > - 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...> > - 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..."> > - 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... oddsock <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-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.