Icecast - Apr 2019 - players who cannot handle switching to a fallback mount point?

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

--

On 12 Apr 2019, at 11:38, Michel van Dop wrote:
> 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>
Hi, Icecast has no `limit-rate` option, only the kh fork has.
In general this list is about Icecast, not Icecast-kh, so you
should at least mention that you use -kh to prevent confusion.
>
> <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.)
>
>
> -- 
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

Before we use the KH version, now we run on debian 9 using the rpm for
Icecast 2.4.4

Marvin Scholz schreef op 2019-04-12 13:30:
> On 12 Apr 2019, at 11:38, Michel van Dop wrote:
> 
>> 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>
> 
> Hi, Icecast has no `limit-rate` option, only the kh fork has.
> In general this list is about Icecast, not Icecast-kh, so you
> should at least mention that you use -kh to prevent confusion.
> 
> <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.)
-- _______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast
_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast 

--
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20190412/f35e9a07/attachment.html>

On Fri, Apr 12, 2019 at 11:38:25AM +0200, Michel van Dop wrote:
> 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.
ffmpeg's ffplay, perhaps?

-- 
Paul Martin <pm at nowster.me.uk>

Hi,

We have setup a test stream using Icecast 2.4.4 and the same icecast 
config.

We use a simple HTML5 player for testing:
<audio controls preload="none">
<source src="https://streamdnsname/aac" type="audio/mp4"
/>
</audio>

See icecast config below. We kick the /aac mountpoint and the html5 
player stop playing.
When we listen to a Winamp player and we kick the /aac it works fine we 
hear the /fk-aac.

[2019-05-07 13:33:25] INFO admin/admin_handle_request Received admin 
command killsource.xsl on mount "/aac"
[2019-05-07 13:33:25] INFO source/source_shutdown Source from x.x.x.x at 
"/aac" exiting
[2019-05-07 13:33:25] INFO source/source_move_clients passing 1 
listeners to "/fk-aac"
[2019-05-07 13:33:25] INFO fserve/fserve_client_create checking for file 
/style.css (/etc/icecast2/web/style.css)
[2019-05-07 13:33:25] INFO source/source_main listener count on /fk-aac 
now 1
[2019-05-07 13:33:29] INFO connection/_handle_source_request Source 
logging in at mountpoint "/aac" from x.x.x.x
[2019-05-07 13:33:29] WARN format/format_get_type Unsupported or legacy 
stream type: "audio/aacp". Falling back to generic minimal handler for
best effort.

Have anyone a ideas what is the problem of the html5 player and Icecast 
config?
Both mountpoints are the same bitrate. Same encoder and settings.

Best regards,
Michel
> 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.)

--

On Tue, May 07, 2019 at 01:59:05PM +0200, Michel van Dop wrote:
> [2019-05-07 13:33:29] WARN format/format_get_type Unsupported or legacy
> stream type: "audio/aacp". Falling back to generic minimal
handler for best
> effort.
Is one source AAC-LC (standard AAC) and the other HE-AAC v2 (AAC+)?

There are three variants of AAC:

AAC-LC
HE-AAC (= AAC-LC with SBR)
HE-AAC v2 (= HE-AAC with parametric stereo), aka AAC+

Check your encoders.

You also have to match all other settings, eg. sample rate.

-- 
Paul Martin <pm at nowster.me.uk>