[icecast] Feature requests - remote dump and optional file split
msmith at labyrinth.net.au
Sat Sep 28 06:41:57 PDT 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