I was thinking more about the <mount> on-connect and disconnect options.
The Icecast docs/guide say the specified scripts are run when that source
(dis)connects, but how does that work for a relay mount, where the actual source
does no such thing. When are those triggers actually run for a relay type mount?
I saw something on Stackexchange that rather suggests these are in fact
triggered when the connection is made to (and broken from) the relayed server,
i.e. the source in this case. So the triggers occur when a connection is made
(and broken) between the source and Icecast and independent of which end
initiated the action. This seems to me to make sense. What else could they be in
a relay mount.
The reason this is then very interesting is that for a relay mount, that
connection would be made (and broken) when the first listener connects and when
the last listener disconnects as that is what Icecast uses to (dis)connect the
relayed source and that is EXACTLY when I need to start and stop the transcoder.
Could anyone possible confirm this. For a relay mount, are the on-connect and
on-disconnect scripts triggered when Icecast connects to and disconnects from
the relayed source?
Ken G i l l e t t
_/_/_/_/_/_/_/_/
> On 10 May 2021, at 09:05, Ken Gillett <kengroups at icloud.com>
wrote:
>
> Yes I was thinking the same about about polling the stats etc, but messy,
really messy. As you say, what is needed are listener (dis)connect hooks. But I
guess slim chance of that.
>
> Even then there would need to be some additional code to figure out how
many listeners to that stream to determine whether transcoder needs to be
started or stopped. While this sort of thing can be done ?externally?, far
better if Icecast handled it internally and provided hooks for ?first listener
connect? and ?last listener disconnect? that could be placed within the
<mount> section.
>
> Even less chance of that. ??
>
>
> Ken G i l l e t t
>
> _/_/_/_/_/_/_/_/
>
>
>
>> On 9 May 2021, at 20:09, Lorenz Reichelt <lr at pripple.de>
wrote:
>>
>> Hi Ken, I suggest you poll the statistics every time the log file
changes (? file system event) and compare the list of streams with at least one
listener with the list of active transcoders. So far for a workaround. I agree,
though, that a on-listener-(dis)connect hook could be useful. ? Lorenz
>