[icecast] a new directory service

Xavier Montero xmontero at dsitelecom.com
Mon Sep 17 10:55:10 UTC 2001



Hello. About your idea, I think that it is important for a radio
to "check" multiple styles.

I'm planning to cast a couple or 3 of stations that are _not_
monographic and will be "sports" from x to y hours, "pop" from
y to z hours, "talk" from z to p hours and so on.

That is because people that are listening the same genre for
hours want to change. Why letting them to switch to another
station? Just give them a variety that does not make them feel
tired to listen.

This is specially true for "live" radio and I think "live" is
not to be considered a genre (as some directories do), but
a property to be filed separately. For example, the genre that
you propose as this:

> genre
>         the genre of teh stream
>         ex.: downtempo or talk

Could be proposed to be defined under a "genre standard" following
this format (I invent it now, so, reply improving this):

Suppose that the genre is to be expressed, in fact as a collection
of genrenames, for example, let's suppose that a radio casts pop
and classical music. The genre could be "pop & classical".
Let's suppose that in fact, the styles are not mixed, simply
they cast pop from 3h to 18h (GMT) and they cast classical from
18h to 3a.m. Then the loop is closed and they start over again.

The syntax could then be: "pop [T= 3:00 - 18:00] & classical [T= 18:00 -
3:00]"
In this case, we provide that "T=" string to identify that we are
going to define a "time" property.

We could also think of "Date" properties (to specify that
genre is "pop" but on "wednesday" it will be "talk"). And we
could think of a different property that applies to every
programming unit: "live radio", "recorded piece of live radio",
or "hard-disc based playlist".

Here I write some kind of "syntax" (I do not follow any
standard, but I try to imitate those who define syntaxes), and
below I give a couple of examples.

Syntax:
        Programming_Unit ["&" Programming_Unit [...]]

Programming_Unit:
        Genre_Name [ Genre_Property [...]]

Genre_Name:
        Any string

Genre_Property:
        "[" Property_ID "=" Property_Data "]"

Property_ID:
        "T" | "S" | "D" | "C"

Property_Data:
        Depends on Property ID.

        If PropertyID is "T", it means "Time"

                GMT_Time "-" GMT_Time

        If PropertyID is "S", it means "Source"

                Source

        If PropertyID is "D", it means "Date"

                Date

        If PropertyID is "C", it means "Classification"

                Any string.

GMT_Time:
        HH ":" MM

Source:
        "R" | "L" | "P"
        (R=Recorded live, L=Live, P= Playlist)

Date:	DayOfWeek | DayOfMonth | FullyQualifiedDate

DayOfWeek:	"Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"

DayOfMonth:	Any integer between [1 to 31]

FullyQualifiedDate:	DayOfMonth "/" Month "/" Year
                        (provided that it makes sense)

Year:		Any integer with 4 digits.

We could add and define a much more rich standard with much
more "tags". But before I loose time writing all possibilities,
I prefer to write down some examples to see if the method is
accepted or people do not like this idea (I hope yes, but
we never know).

For example, let's suppose that I want to listen to talk radio
talking about computers: I perform a search: "talk computers"
and I could find a radio that outputs this result:

"
slowtempo [T= 00:00 - 08:00] [S=P]
talk      [T= 08:00 - 12:00] [S=L]              [C= Sports]
talk      [T= 12:00 - 14:00] [S=L]              [C= News]
talk      [T= 14:00 - 18:00] [S=L]              [C= Magazine]
mixed     [T= 18:00 - 22:00] [S=P]              [C= Pop, Rock,
Contemporary]
talk      [T= 22:00 -  0:00] [S=R]              [C= Social]
dance     [T= 22:00 -  0:00] [S=R] [D=Sun]
talk      [T= 22:00 -  0:00] [S=R] [D=Mon, Fri] [C= Computers]
"

Then we could think that this radio perhaps does not talk about
computers just now but but, if GMT is on monday and it is 20:00
in a couple of hours I'll be able to listen what I want.

As an added value, you could ask the directory to send some
bookmarks and/or call your attention by mail or other methods.
For example, I want to listen to "Economy" and we are on
saturday. Let's suppose that a radio has the following line:

talk [T= 15:00 16:00] [S=L] [D=Fri] [C=Economy]

Then a simple link "beside" the programming unit (the directory could
interpret the syntax and present it finely on a html table) could
say "remember me one day before" and/or "remember me [??] hours before"

Then the user (only if he has a login) is notified by mail on
the next Thursday:

Subject: Icecast Directory Remember Service
Body:
Remember that on xx/xx/xxxx at xx:xx you wanted to listen to:
Radio XXXXX at http://hnjkcdhejkceh:45854218
- Click "here" to listen
- Click "here" to remember in [xxx] hours
- Click "here" to remember again "xxx" hours before the event starts

Also, as a secondary effect, this could be used to send
"mail-bookmarks" to the users because they can store in a
mail-folder some quantity of messages similar to this:

Subject: [Directory Bookmark] Radio XXXXXXXX
Body: Radio XXXXXXX is at http://hvdjjhvihwviuw:4678239

Now I place this in mode "request for comments"
See you!
Xavi.

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



More information about the Icecast mailing list