I wanted to use the Icecast dumpfile for hourly stream archival, so I added a
signal handler to trigger the re-opening of dumpfiles. This lets me rename the
dumpfile, signal Icecast, and repeat. Patch is attached.
I've never spent any time in the Icecast source before now, so I had a
couple of questions/thoughts:
1. Since all I needed was to trigger a re-open, I went with a new signal &
handler (SIGUSR1). But this could have been just as easy to attach to the
current HUP handler. In fact, it would have probably been easier, since
there'd be no need to duplicate the techniques already used to propagate the
message (handler sets global flag, client thread sees flag and triggers event).
2. In my event function, I lock the source tree before iterating it. Is that
necessary? I used a read lock, since I'm not modifying the tree structure
itself... but while iterating, I set a flag in each source to request that the
source re-open its dumpfiles. Does that mean I should have used a write lock
instead?
3. I implemented the re-open in source.c rather than in the individual format
plugins, which may have been naive of me. I'm dealing strictly with MP3 data
here, so I can split the file anywhere. Other formats may not take so kindly to
arbitrary stream splits.
I'd love to see this integrated and would be glad to tweak/retool as
necessary.
--
Ken Treis
Miriam Technologies, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reopen-dumpfiles.diff
Type: application/octet-stream
Size: 4017 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/icecast-dev/attachments/20110223/beda7eed/attachment.obj
