[icecast] a new directory service

[Marek Pawlowski]

On September 17, 2001 01:31, you wrote:
> So I've been doing some research and thinking here and there about what
> a _good_ directory service for icecast would be like.  I'd appreciate
> some feedback and some discussion on this topic, before I start putting
> a lot of effort into developing it.
>
> First off, I think getting rid of # of listeners is a must.  It just
> creates a self-fulfilling prophecy and encourages cheating.  I think the
> best way to facilitate finding streams that you really want to listen to
> is to make the information sortable, searchable, and filterable etc.
> I'll probably be making a stand alone client to help with this, although
> the web interface will still be there.  How else can we present the
> information that takes the focus off of stupid, irrelevant things like
> number of listeners?

I'm going to have to take the opposite point of view on this one, but with a 
slight modification..  Number of listeners is not irrelevant, especially to 
broadcasters and their competition.  Granted, broadcasters get their own 
statistics with more detail than just a simple number - so the information is 
still there -  but I think it's a bit of a stretch to go as far as to say 
that the number is irrelevant, rather, it's relevance has been misconstrued 
to mean other things.  My personal reason for paying attention to this 
statistic when faced with thousands of possible streams is that I am looking 
for music of a specific genre and stand a better chance of landing in a 
stream that actually falls in to that category when it's being listened to by 
a majority of people (e.g. It leaves the general impression that a consensus 
has been reached as to the quality of the stream and the accuracy of it's 
description.)  Of course, this is simply a hacked way of making up for the 
various shortcomings of current directory services and broadcaster oversights 
and doesn't always work, but it helps.  I imagine that other people use this 
logic extrapolated to meet their own personal needs and desires.

Furthermore from a listeners point of view, it does seem to be a powerful 
general motivator/gravitator ("What is everyone else listening to?"  "Where's 
the party at?") to plug in to a stream based on number of listeners - this 
technology we're using is unique in giving us that ability, taking advantage 
of it is not a bad thing in my opinion, tied in with the fact that we are 
social animals and like to hang out in groups it almost seems as a necessity 
to me and has the potential to adversely affect the success of such a 
directory listing after having people conditioned by other directory 
services, hit counters, etc..

That said, we are all aware of the fact that there is a large amount of 
cheating going on, and therefore that number may not be so relevant nor 
accurate.  In addition, the abovementioned sentiment that seems common among 
listeners has created an undesired emphasis on this head count, which I think 
is the actual root of the problem.  Perhaps one or all of two things can be 
done to filter down it's importance while getting the same kind of usability 
in the grand scheme of things in addition to investigating as to how cheating 
can be significantly reduced:

1 - Represent the listeners on a different scale (was it live365 that 
represented listeners by displaying one to four stars?)

2 - Don't sort streams according to their alleged listenership (maybe even go 
so far as not allowing that column to be sorted), certainly don't present the 
default listing of streams prioritized by this statistic.

In the case that number of listeners is no longer a value displayed to the 
public I would place emphasis on *greatly* increasing the accuracy/importance 
of other statistics to compensate for this possible removal, which is what I 
think Jack is trying to accomplish below anyway.  At least I've got to voice 
my opinion that I feel it's a valuable statistic and rather would like to see 
effort put in to strengthening it's validity while representing streams 
without this number being the primary emphasis ...  :)

> Here's my current list of information that each directory entry would
> contain.  If you don't understand what 'auth' is, don't worry.  it's
> there to provide a modicum of security.  What else would you guys like
> to see or think should be there?

I'll add my musings below, though I am quite aware that some of it may break 
some rules :)

> DIRECTORY VALUES
> ================
>
> url
> 	the url to the stream
> 	ex.: http://streams.vorbis.com:8000/downtempo.ogg

In general:  What about exploring the possibility of having multiple bitrates 
of the same stream represented on the same row (perhaps 'auth' is geared for 
enabling that kind of functionality)?

> type
> 	type of the stream
> 	ex.: audio/mpeg or application/ogg
>
> bitrate
> 	bitrate of the stream in kilobits per second
> 	ex.: 64

Though we all know what kbps is, your average listener simply knows if they 
have a modem, cable, DSL, or whatever.  Though I would never want kbps to go 
away, maybe there's a complimentary way to represent that figure in terms 
that your average listener will understand.

> name
> 	the name of the stream
> 	ex.: Jack's Funky Beats
>
> genre
> 	the genre of teh stream
> 	ex.: downtempo or talk

I'd like to see sub-genre(s) or a method to allow for tighter genre 
definitions..  Let me illustrate by this observation:  There's techno, and 
then there's Techno - why? - because people aren't always aware of the proper 
genre, some people call all electronic music techno, while others are far 
more specific.  We've had to resort to this minor, silly distinction..  It'd 
be nice not to have to use valuable space in the description field to 
emphasize that indeed one does play 'proper' techno, or a specific sub-set of 
the genre.  Having an optional subgenre would allow broadcasters not to be 
left behind when sorted on a general list of streams while still being able 
to accurately portray their stream and let people find them with ease.

> homepage
> 	the homepage of the stream
> 	ex.: http://streams.vorbis.com/
>
> email
> 	email address of the streams maintainer
> 	ex.: jack at xiph.org

A couple more suggestions shot from the hip:

world coordinates
        Optional longitude/latitude values that can be used for representing the 
location of the stream in a variety of ways; on a map, text, etc.  Could also 
be used for determining the timezone of the stream.

type
        A boolean distinction between live and playlist driven streams

alternate contact
        A general text field that can include alternate methods of being in touch 
with the people behind the particular stream.
        ex.: Phone number for the studio
               ICQ/AIM id
               IRC channel
               Link to another URL that can be used to trigger a chat system, 
message board, voting mechanism or something..

> description
> 	short description of the stream
> 	ex.: All the funkiest beats from the funkiest people.  Tune
> 	in now for some great downtempo music.
>
> ttl
> 	time to live.  number of minutes  an entry is valid for.  subsequent
> 	directory changes will refresh this value.  when the value
> 	reaches 0, this entry will be removed.
> 	ex.: 5
>
> auth
> 	authorization string.  this is a md5sum of of some
> 	random data.
> 	ex.: echo 'jack at xiph.org|Jack Moffitt|password' | md5sum
>
>
>
> jack.

- Marek

--- >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-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.