[Icecast] Transcoding

[Ken Gillett]

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 
>