[Icecast] When switching from source client to fallback and back glitches listen client

[Jack Elliott]

@Dik ....


Thank you for the suggestion. I've glanced over the documentation for 
Liquidsoap a few times and it looks like a powerful tool with a learning 
curve. I didn't see a good reason to use it for our simple needs, but if 
it's what I have to use to paper over the rough switching from a live 
remote host's Icecast stream to a local fallback file, then I reckon 
I'll need to get into it.


This forum is not the place for Liquidsoap so I'll shift over to a more 
appropriate place to learn more.

-- 
Jack Elliott
Director of Classical Music Programming
High Desert Community Radio
KPOV Bend, Oregon

On 9/20/23 9:27 AM, Dik .... wrote:
> I suggest you look at Liquidsoap.  Particularly mksafe which can merge 
> files together into a single stream and stop clients from disconnecting
>
> https://www.liquidsoap.info/doc-2.2.0/quick_start.html#that-source-is-fallible
>
>
> ------------------------------------------------------------------------
> *From:* Icecast <icecast-bounces at xiph.org> on behalf of Fred Gleason 
> <fredg at paravelsystems.com>
> *Sent:* 18 September 2023 16:09
> *To:* thatjackelliott at kpov.org <thatjackelliott at kpov.org>; Icecast 
> streaming server user discussions <icecast at xiph.org>
> *Subject:* Re: [Icecast] When switching from source client to fallback 
> and back glitches listen client
> On Sep 16, 2023, at 13:58, Jack Elliott <that.jack.elliott at gmail.com> 
> wrote:
>
>> I've noticed that when a source-client disconnects from the 
>> mountpoint and the mountpoint switches to its specified 
>> fallback-client, some listen-clients disconnect, or close, or 
>> otherwise glitch. Same thing when a remote source-client connects, 
>> dropping the fallback--the listen-client can glitch.
>>
>> The fallback is an mp3 encoded at the same sample rate and bitrate as 
>> the remote source-client.
>>
>> It shouldn't glitch stream players just because it swaps sources, 
>> should it?
>
> I suspect that what is going on is that the two streams (original and 
> fallback) are not precisely synchronized, which means that the decoder 
> will likely lose framing when switching to the fallback bitstream and 
> hence mute or otherwise glitch while reacquiring same. I’m pretty sure 
> that this is a consequence of the basic architecture of the Icecast 
> system.
>
> Cheers!
>
>
> |---------------------------------------------------------------------|
> | Frederick F. Gleason, Jr. |             Chief Developer           |
> |                     |             Paravel Systems     |
> |---------------------------------------------------------------------|
> |   A room without books is like a body without a soul.     |
> |     |
> |                                                   -- Cicero   |
> |---------------------------------------------------------------------|
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20230921/f6b0c6cb/attachment.htm>