Icecast dev - Aug 2004 - ices: forcing an immediate reread of the playlist

Hi all,

        I'm currently trying to set up ices2 with icecast2 along with otto,
a
jukebox interface written in perl. Otto allows the user to kill a song via 
the web interface, which in turn kills all running instances of ices, 
rewrites the playlist and launches ices. This has the bad side effect of 
terminating the client's connection to icecast and leaving a bunch of ices 
dangling . I'd like to be able to have otto spawn a single instance of ices 
at startup, and then signal ices when the user has selected the next song.

        As far as I can tell im_playlist doesn't check for pl->nexttrack
until it
is at the end of the file. What would be the best way to force this tight 
loop to immediately reread it's playlist? I see two options

1. Write some extra code to check for a nexttrack == 1 inside the while(1) 
playlist_read
2. Force pl->current_file to the end of the stream

The only reason I hesitate on 2 is that I'm wondering what side effects 
forcing a "zip" to the end of the file would have on the ogg state.

Any insight or pointers would be of great help.

Thanks,
Brant Chamberlain

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

i have a hacked version of otto that i've fixed up to address a number
of problems along these lines.

i contacted the author of otto about my poatches and he never
responded.

if you like i can tar it up and send it to you. my changes are not
well documented though.

rob

Brant Chamberlain writes:
 > Hi all,
 > 
 > 	I'm currently trying to set up ices2 with icecast2 along with otto, a
 > jukebox interface written in perl. Otto allows the user to kill a song via
 > the web interface, which in turn kills all running instances of ices, 
 > rewrites the playlist and launches ices. This has the bad side effect of 
 > terminating the client's connection to icecast and leaving a bunch of
ices
 > dangling . I'd like to be able to have otto spawn a single instance of
ices
 > at startup, and then signal ices when the user has selected the next song.
 > 
 > 	As far as I can tell im_playlist doesn't check for pl->nexttrack
until it
 > is at the end of the file. What would be the best way to force this tight 
 > loop to immediately reread it's playlist? I see two options
 > 
 > 1. Write some extra code to check for a nexttrack == 1 inside the while(1)
 > playlist_read
 > 2. Force pl->current_file to the end of the stream
 > 
 > The only reason I hesitate on 2 is that I'm wondering what side
effects
 > forcing a "zip" to the end of the file would have on the ogg
state.
 > 
 > Any insight or pointers would be of great help.
 > 
 > Thanks,
 > Brant Chamberlain
 > 
 > 
 > --- >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.
 > 

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

Hi Michael,

         I'll try, but just from looking at the code inside im_playlist.c 
it doesn't appear to check the pl->nexttrack variable inside the
'while(1)'
loop unless it reaches the eof on the playlist file. Honestly I don't 
understand the ogg function calls, but just wondering if code has to be 
added to check this.

Brant

At Tuesday 06:24 PM 3/19/2002, Michael Smith wrote:
>At 12:32 PM 3/19/02 -0500, you wrote:
> >Hi all,
> >
> >       I'm currently trying to set up ices2 with icecast2 along
with
> otto, a
> >jukebox interface written in perl. Otto allows the user to kill a song
via
> >the web interface, which in turn kills all running instances of ices,
> >rewrites the playlist and launches ices. This has the bad side effect
of
> >terminating the client's connection to icecast and leaving a bunch
of ices
> >dangling . I'd like to be able to have otto spawn a single instance
of ices
> >at startup, and then signal ices when the user has selected the next
song.
> >
> >       As far as I can tell im_playlist doesn't check for
pl->nexttrack
> until it
> >is at the end of the file. What would be the best way to force this
tight
> >loop to immediately reread it's playlist? I see two options
>
>It'll skip to the next file if you send ices SIGHUP (I think. I may have
>ended up using a different signal). It definately doesn't wait until
>end of file to check that.
>
>Michael
>
>
>--- >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.
<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.

At 12:32 PM 3/19/02 -0500, you wrote:
>Hi all,
>
>	I'm currently trying to set up ices2 with icecast2 along with otto, a 
>jukebox interface written in perl. Otto allows the user to kill a song via 
>the web interface, which in turn kills all running instances of ices, 
>rewrites the playlist and launches ices. This has the bad side effect of 
>terminating the client's connection to icecast and leaving a bunch of
ices
>dangling . I'd like to be able to have otto spawn a single instance of
ices
>at startup, and then signal ices when the user has selected the next song.
>
>	As far as I can tell im_playlist doesn't check for pl->nexttrack
until it
>is at the end of the file. What would be the best way to force this tight 
>loop to immediately reread it's playlist? I see two options
It'll skip to the next file if you send ices SIGHUP (I think. I may have
ended up using a different signal). It definately doesn't wait until
end of file to check that.

Michael

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