[icecast] ices 'script' playlist information?

Michael Smith msmith at labyrinth.net.au
Sat Mar 1 17:44:59 PST 2003

Adam Scriven <scriven at lore.com> said:

> On Sat, Mar 01, 2003 at 07:09:24PM +0000, Karl Heyes wrote:
> > On Sat, 2003-03-01 at 18:41, Adam Scriven wrote:
> > > Is there anywhere I can go to get detailed information on how this works?
> > > I'm wondering about passing information back and forth, for example, or
> > > if there's anyway to collect information like the audio program they're
> > > listening with, or perhaps passing "state" information back and forth.
> > 
> > The script playlist runs a program (can be anything executable) and that
> > just sends to it's standard output a series of filenames (typically
> > absolute paths) of ogg files to play.  Each filename is read and is used
> > to find a file to play, anfter that has finished then another filename
> > is read.
> Actually, from the tests that I've done, ices only uses the first song the
> script outputs.
> I have a script that right now is very simple, it bascially just prints out
> two songs to play, each "line" ending in \n.
> What happens is, it plays the first song, then re-runs the script to get the
> next song, but since the script just prints out lines, it re-prints the first
> line first again, and ices logs this:
> "EROR playlist-builtin/playlist_read Cannot play same file twice in a row,
> It never reads the second "line" outputted from the file.
> So, without any state information being passed back and forth from audio
> program<->icecast<->ices, the only way left to track the state of the script
> is to read/write external files.  That seems a bit inelegant to me, but that's
> MNSHO, and maybe I'm screwing something up.
> :)

No, you're exactly right. The script module is relatively primitive - it was
intended mostly as a somewhat useful, but simple proof-of-concept. The intent
was to eventually (optionally) have stateful in-process scripts (using perl or
python, as ices 0.x allows) as another playlist module. I never got around to
writing those - maybe someone (you?) is interested in doing so? I think the
ices 0.x code for that should be adaptable to ices2 without too much difficulty.

> > ices has no way of telling you whats been used to play streams as that
> > is inside icecast, there is practically no feedback from icecast. It
> > sounds like you want something from icecast itself.
> Yeah, I hadn't realised that when I asked the question.  I'd forgotten icecast
> was there, it's working so well. (Loaded up the server and forgot about it.
> Isn't that how they're supposed to work? :) )
> So, is there anyway to make icecast and ices communicate that information,
> or will I need to just track that information myself with external files or
> something?

The communication between ices and icecast is essentially (apart from some
optional connection negotiation stuff at the start) one-way only.


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