Icecast - Jan 2006 - [Icecast-dev] metadata fallback mounts

Karl Heyes wrote:
> To maintain consistency, no timing occurs on the fallback to file as that 
> requires parsing of all formats.
hmmm, good point, but it obviously breaks fallback-override (as far as it's 
useful), and also could cause your outgoing bandwidth to be swamped.

Suggestion: How about allowing the admin to configure a bitrate for the 
fallback file.  This would make it their responsibility to get it right, 
but would solve both of the above.

Geoff.

Geoff Shang wrote:
> Karl Heyes wrote:
> 
>> To maintain consistency, no timing occurs on the fallback to file as 
>> that requires parsing of all formats.
> 
> 
> hmmm, good point, but it obviously breaks fallback-override (as far as 
> it's useful), and also could cause your outgoing bandwidth to be
swamped.
It's not that fallback override breaks, but there may be lot of stream 
data sent to that listener. There is a delay each time around the main 
handler to limit busy looping.
> Suggestion: How about allowing the admin to configure a bitrate for the 
> fallback file.  This would make it their responsibility to get it right, 
> but would solve both of the above.
That is certainly possible, I was wondering about implementing such a 
mechanism as a simple regulator but never got around to implementing it.


karl.

At 08:11 AM 1/19/2006, Karl Heyes wrote:
>Geoff Shang wrote:
>>Karl Heyes wrote:
>>
>>>To maintain consistency, no timing occurs on the fallback to file 
>>>as that requires parsing of all formats.
>>
>>hmmm, good point, but it obviously breaks fallback-override (as far 
>>as it's useful), and also could cause your outgoing bandwidth to be
swamped.
>
>It's not that fallback override breaks, but there may be lot of 
>stream data sent to that listener. There is a delay each time around 
>the main handler to limit busy looping.
>
>>Suggestion: How about allowing the admin to configure a bitrate for 
>>the fallback file.  This would make it their responsibility to get 
>>it right, but would solve both of the above.
>
>That is certainly possible, I was wondering about implementing such 
>a mechanism as a simple regulator but never got around to implementing it.
personally I wouldn't mind seeing the fallback to file implemented as 
a simple source loop creation.  This would create another source 
thread (inefficient maybe, but then it could be treated just like any 
other source).  This would also add another dependency to icecast (it 
would add libshout), which might be a bit problematic, but still 
worth looking at...I know icecast already shares a lot of code with libshout

oddsock