[Icecast] players who cannot handle switching to a fallback mount point?

[Michel van Dop]

Hi Paul,

Thanks for the quick response!
We use the same type of encoder (Sam Cast) both live for both 
mountpoints on 96 Kb Joint Stereo.

it is difficult to see if it is exactly the same. Is there a player that 
show exactly this? I will check this.

We have use the limit-rate in our config. Thats work better for go to 
play the last fallback-mount file (i test this).

See here our part of the config:

<mount>
<mount-name>/aac</mount-name>
<password>xxxxxxx</password>
<public>1</public>
<hidden>0</hidden>
<limit-rate>96k</limit-rate>
<fallback-mount>/fk-aac</fallback-mount>
<fallback-override>1</fallback-override>
<max-listeners>1500</max-listeners>
</mount>

<mount>
<mount-name>/fk-aac</mount-name>
<password>xxxxxxx</password>
<public>1</public>
<hidden>1</hidden>
<limit-rate>96k</limit-rate>
<fallback-mount>/aac.aac</fallback-mount>
<fallback-override>1</fallback-override>
<max-listeners>1500</max-listeners>
</mount>

Best regards,

Michel


Paul Martin schreef op 2019-04-12 11:13:

> On Fri, Apr 12, 2019 at 09:30:11AM +0200, Michel van Dop wrote:
> 
>> We use Icecast version 2.4.4 and use mountpoint /main and include use
>> fallback-mount.
>> When the /main is offline 92% of the listeners go to fallback-mount 
>> and
>> 8% disconnect.
>> 
>> The format is 96k AAC and we have 8 mountpoint and 8 fallback-mount
>> points include extra fallback files AAC.
> 
> Are the fallback streams exactly the same characteristics as the
> streams they're associated with?
> 
> Are they live or are they files served by Icecast?  (File serving is
> not bitrate constrained in mainstream Icecast, so will completely fill
> listeners' players' buffers, possibily requiring a reconnect to get
> back to live if the buffer is large.)


--