[Icecast] falling back

[Petr Pisar]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20210521/0256a959/attachment.sig>