Icecast dev - Apr 2008 - Caching current events for new listeners

> you can't keep them in the main queue because you are subject to the
> queue size cutoff so you either keep this within the per codec handle
> structure (codec list) and/or in the block for the header pages (via the
> associated pointer).  The sending handlers are not really codec aware
> but they do notice a change in headers.
Yes, but that's the problem I'm facing:

- if I keep them in the codec specific struct (which is what I'm doing now),
I can't request them when a new listener connects, as I don't know when
this happens from the format_ogg.c code

- if I keep them (and update them as streaming goes on) in the headers list,
then send_ogg_headers will continuously stream them out, but I don't want
that since that'll get pushed to all listeners, and they'll have already
gotten
those as normal streaming progresses.

Cheers

ogg.k.ogg.k at googlemail.com wrote:
> - if I keep them in the codec specific struct (which is what I'm doing
now),
> I can't request them when a new listener connects, as I don't know
when
> this happens from the format_ogg.c code
> 
> - if I keep them (and update them as streaming goes on) in the headers
list,
> then send_ogg_headers will continuously stream them out, but I don't
want
> that since that'll get pushed to all listeners, and they'll have
already gotten
> those as normal streaming progresses.
There are certain things that could be done to help the situation, I'm 
not sure which would be best in your particular case but the current 
sync_point setting could be turned into a general bitmask flags, where 
sync point is just one and you can have codec specific allocations of 
those flags.

Also the check_buffer routine is called before the send_to_listener. 
It's used to populate data from intro/fallback files or progress through 
the queue. You could set a special check buffer handler that checks the 
above refbuf_t flags. It's possible to create a per-client refbuf_t 
within there that hooks back into the queue.

karl.

Thanks for the pointers, I'll have a look at those.

Cheers