[Icecast] falling back

Fri May 21 17:28:42 UTC 2021

I’m afraid this will be a little long, but hope some can put in the time to read and help.

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.

Testing with a player (ffplay) to connect to the BBCR2 (relay) mount, it plays silence and this is what Icecast says:-

[2021-05-21  17:20:53] INFO slave/start_relay_stream Starting relayed source at mountpoint "/BBCR2"
[2021-05-21  17:20:53] INFO slave/open_relay_connection connecting to 127.0.0.1:8127
[2021-05-21  17:20:53] INFO source/source_main listener count on /silence.aac now 1
[2021-05-21  17:20:53] WARN format/format_get_type Unsupported or legacy stream type: "audio/aac". Falling back to generic minimal handler for best effort.
[2021-05-21  17:20:54] INFO source/source_main listener count on /BBCR2 now 1

Ignoring the legacy WARN, when the listener connects to BBCR2, it tries to relay from BBCR2.aac which has no source and so plays the silence.aac (ADTS format) file. All correct so far, except the on-connect script (that starts transcoding and streaming to BBCR2.aac) is not run. More on that later.

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? Surely the fallback file should simply loop indefinitely until the real source comes on line - which it doesn’t as the script is not run.

Now I try the same thing, but manually running the script that will start the transcoder and send the stream to Icecast’s BBCR2.aac mount:-

[2021-05-21  17:23:48] INFO slave/start_relay_stream Starting relayed source at mountpoint "/BBCR2"
[2021-05-21  17:23:48] INFO slave/open_relay_connection connecting to 127.0.0.1:8127
[2021-05-21  17:23:48] INFO source/source_main listener count on /silence.aac now 1
[2021-05-21  17:23:48] WARN format/format_get_type Unsupported or legacy stream type: "audio/aac". Falling back to generic minimal handler for best effort.
[2021-05-21  17:23:49] INFO source/source_main listener count on /BBCR2 now 1
[2021-05-21  17:24:04] INFO connection/_handle_source_request Source logging in at mountpoint "/BBCR2.aac" from 127.0.0.1
[2021-05-21  17:24:04] WARN format/format_get_type Unsupported or legacy stream type: "audio/aac". Falling back to generic minimal handler for best effort.
[2021-05-21  17:24:04] INFO source/source_move_clients passing 1 listeners to "/BBCR2.aac"
[2021-05-21  17:24:04] INFO source/source_main listener count on /BBCR2.aac now 1
[2021-05-21  17:24:04] INFO source/source_main listener count on /silence.aac now 0

So initially the same as the first run, but then it sees the source for BBCR2.aac and switches the listener from the file to that mount - as it should. But I still don’t hear the actual radio stream because same as last time:-

[2021-05-21  17:24:23] INFO source/send_to_listener Client 380 (xxx.xxx.xxx.xxx) has fallen too far behind, removing
[2021-05-21  17:24:23] INFO source/source_main listener count on /BBCR2 now 0
[2021-05-21  17:24:23] INFO source/source_shutdown Source from 127.0.0.1 at "/BBCR2" exiting
[2021-05-21  17:24:23] INFO source/source_main listener count on /BBCR2.aac now 0

Leaving me to manually stop ffplay and run the transcode stop script.

So several questions:-

Why does Icecast complain about the client being ’too far behind’ and how can I prevent this? Surely the fallback should simply operate as long as necessary? Is this the ‘looping too fast’ problem that is swamping the client? How is this fallback file feature supposed to work?

Why when switching the listener back from the fallback file to the actual streaming source do I still not hear that? Is this perhaps just because of the previous issue?

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).

As I said, sorry it’s a bit of a long one, but hope some more experienced in Icecast than me can shed some light on this.

Ken  G i l l e t t

_/_/_/_/_/_/_/_/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20210521/d29c933e/attachment.htm>