[Icecast] falling back

[Marvin Scholz]

As Petr Pisar already mentioned, what you are trying to do
is really something Icecast is not really made for currently,
so it might be very tricky to get it working properly.

To the problem about the client falling behind, this can be caused
by mostly two thinks in this case, that I can think of:

1. If you are not streaming the fallback mount to Icecast, it will
    not pace it but just send it as fast as possible to the client.
    That means the client will eventually have lots of data that it
    has to play first, possibly causing it to get delayed too much
    due to buffer size limits in the client.

2. If the stream is absolute silence, like Petr mentioned, the
    compression can be so efficient that you kind of end up with
    a similar problem as in 1. so its usually recommended to not do
    complete silence as fallback but some comfort noise.

So the issue you are facing is probably one of the two above or even
a combination of those.

On 21 May 2021, at 21:50, Petr Pisar wrote:

> V Fri, May 21, 2021 at 06:28:42PM +0100, Ken Gillett napsal(a):
>> As I mentioned, I need to transcode and want Icecast to start and 
>> stop
>> according to listeners. So this is what I’m trying:-
>>
>> 	<relay>
>> 		<server>127.0.0.1</server>
>> 		<port>8127</port>
>> 		<mount>/BBCR2.aac</mount>
>> 		<local-mount>/BBCR2</local-mount>
>> 	</relay>
>> 	<mount type="normal">
>> 		<mount-name>/BBCR2</mount-name>
>> 		<public>0</public>
>> 		<on-connect>/usr/local/bin/transtart</on-connect>
>> 		<on-disconnect>/usr/local/bin/transtop</on-disconnect>
>> 	</mount>
>> 	
>> 	<mount type="normal">
>> 		<mount-name>/BBCR2.aac</mount-name>
>> 		<public>0</public>
>> 		<fallback-mount>/silence.aac</fallback-mount>
>>     	<fallback-override>1</fallback-override>
>> 	</mount>
>>
>> So the first 2 blocks are the relay mount that ‘pulls’ from the 
>> mount
>> configured in the 3rd block. Yes, this does work, Icecast CAN relay 
>> from
>> itself. The reason why I do this is to take advantage of the 
>> on-(dis)connect
>> scripts and the fact that an Icecast relay only ‘pulls’ when 
>> there are
>> listeners for that mountpoint.
>>
> In my opinion you cannot achieve what you want with Icecast because it 
> goes
> against its design.
>
> Icecast has two types of mount points: source-mounts which content is 
> pushed
> into Icecast and relay-mounts which content is pulled by Icacast.
> A transmission of the content which is pulled can only be initiated by 
> Icecast.
> On the other hand, the pushed content cannot be initiated by Icecast. 
> The
> pushed content is always initated by an external stream source 
> (transcode in
> your case).
>
> Basically, Icecast is a streaming proxy of which task is to multiply 
> an external
> source to multiple clients at the same time. The external source is 
> either
> pushed or pulled content. Streaming local files is only a trivial tool 
> for
> providing a fallback when the external source is unavailable.
>
> What you need is an transcoder which waits on a connection from an ICY 
> client
> and then it opens a tunner and starts transcoding. And similarly it 
> will close
> the tunner after the client disconnects. The transcoder does not need 
> and
> should not be able to handle multiple clients. It should be a trivial 
> program
> for one tunner and one client. After having this setup, you can place 
> Icecast
> between the transcoder and the (thousands of) clients.
>
> I cannot recommend you any ready-made transcoder because I have no 
> experience
> in this area. But I believe there exist plenty of transcoders which 
> can work
> as a source-client for Icecast and thus it should be easy to enhance 
> them to
> implement a one-client ICY server (the pull model from Icecast point 
> of view)
> in addition.
>
> (Technically it could be possible to introduce a third type of a mount 
> type
> to Icecast: It would execute an external command for the first client,
> streamed its standard output and terminated the command with the last 
> client.
> But handling execution of possibly blocking commands adds more 
> complexity and
> from security point of view its not wise to give Icecast server a 
> permission
> to access various hardware (e.g. tunners) directly.)
>
>> However, about 35 seconds after this first starts (i.e. listener 
>> connects to
>> BBCR2), Icecast logs this:-
>>
>> [2021-05-21  17:21:28] INFO source/send_to_listener Client 377 
>> (xxx.xxx.xxx.xxx) has fallen too far behind, removing
>> [2021-05-21  17:21:28] INFO source/source_main listener count on 
>> /BBCR2 now 0
>> [2021-05-21  17:21:28] INFO source/source_shutdown Source from 
>> 127.0.0.1 at "/BBCR2" exiting
>> [2021-05-21  17:21:28] INFO source/source_main listener count on 
>> /silence.aac now 0
>>
>> So Icecast kills everything, but the listener (ffplay) doesn’t know 
>> this and
>> continues running, obviously still silent so I cannot tell what it 
>> actually
>> thinks it is playing.  Why does Icecast say the Client (ffplay on my 
>> Mac at
>> xxx.xxx.xxx.xxx) is too far behind?
>
> I think this message means that the client does not consume the 
> stream. So an
> output buffer on the server has been filling up and after 35 seconds 
> reached
> a limit and thus the server disconnected the client.
>
> I recommend you either to replace the silent stream with something 
> audiable,
> or better use a network analyzer tool (e.g. tcpdump) to see whether 
> the stream
> flows from the server to the client or not.
>
> I suspect that either the client misunderstands the stream, or the 
> server
> misunderstands the /silence.aac file.
>
>> Why are the scripts not run? It seems to me that when the relay 
>> receives
>> anything, whether from the relayed mount (BBCR2.aac in this case) or 
>> its
>> fallback file, that event is the source connecting and should trigger 
>> the
>> on-connect script. But it does not. The script writes a log and I can 
>> see it
>> is simply not being run at all (unless I run it manually).
>>
> Does something change if you remove the second block (mount at 
> /BBCR2)?
>
> I think it does not call the scripts because you defined /BBCR2 twice. 
> Maybe
> Icecast parser does not expect having them twice, ignores the second
> block and uses only the first one.
>
> -- Petr
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast