[icecast] Feature requests - remote dump and optional file split

Michael Smith msmith at labyrinth.net.au
Sat Sep 28 13:41:57 UTC 2002

At 10:34 PM 9/28/02 +1000, you wrote:
>I've been hired to provide, among other things, internet coverage for a
>convention in 2 weeks.  I have two feature requests, one highly desired and
>one moderately desired.
>My moderately desired feature has been mentioned before - server-side
>recording of the stream.  As in the cases mentioned previously, I'd like to
>be able to repeat segments without having to upload them first.  Since I'll
>be using a modem on site, I'd have to spend 3 hours of down-time uploading
>a dump of a 3-hour session before it could be repeated server-side.  This
>is only moderately desired because, if push came to shove, I could repeat
>it from the site itself if necessary, though I'd have to keep the line up.

This is straightforward, and could be added pretty quickly and easily. 
I don't currently have time to do so, however, so you'll either have to
wait (which presumably isn't an option, since you have a 2 week deadline),
develop it yourself, or find someone else who could add it.

If anyone IS interested in writing this, it should only take a couple of
hours, and I'm happy to help people with detailed advice, if needed.

>The highly desired feature also relates to repeats.  I notice that ices now
>allows for sending new tag information upon receipt of a signal.  This is
>very useful as it allows you to keep the listener informed as to what
>they're listening to.  I would like to be able to configure ices or icecast
>to start a new dump file when this happens.  The reason for doing this is
>that I can then delete the ones I don't want and rerun the various sessions
>without rerunning the time between them.  Obviously this setup won't suit
>everyone - someone doing a music show wouldn't want it for example, but
>someone in my position would find it useful.

This isn't going to be possible easily. icecast doesn't know anything 
about the boundaries at the appropriate level (only in the low-level ogg
parsing module), and the design is such that it really doesn't make sense
to lift this information up into the core. This feature would make a lot
more sense in ices (where it would be simple to add - ices knows all about
the boundaries, and already has stream-dumping functionality). 

>Unfortunately I don't have the programming skills to make these features a
>reality, but I would certainly be greatful and will use them at the
>convention if they appear.


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