subscription at nextdial.com.br
2018-May-23 01:46 UTC
[Icecast] Why "has fallen too far behind"?
Hello,
We are seeing in Firebase this kind of errors:
com.google.android.exoplayer2.upstream.HttpDataSource$InvalidResponseCodeExc
eption: Response code: 401
So, after 12h trying to reproduce the error we saw what's happening. If
the listener connection buffer due to anything, Icecast remove it's
connection and log the item bellow:
[2018-05-22 23:17:24] INFO source/send_to_listener Client 220977
(xxx.xxx.xxx.xxx) has fallen too far behind, removing
My question is:
Why Icecast need to do this? Why the client can't reconnect? The error
401 is when the client tries to reconnect and our auth deny?
Best,
Thiago
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20180522/6fbe411d/attachment.html>
"The man with two clocks knoweth not the time."
The audio source clock does not match the audio destination clock, and
sooner or later, something needs to "give." This causes buffer
under/over
flows.
The ICY protocol has no provision for timestamps which can be used to help
circumvent this in player clients, if supported.
HLS and DASH have this ability.
/greg.
StreamS
From: Icecast <icecast-bounces at xiph.org> On Behalf Of
subscription at nextdial.com.br
Sent: Tuesday, 22 May, 2018 18:46
To: icecast at xiph.org
Subject: [Icecast] Why "has fallen too far behind"?
Hello,
We are seeing in Firebase this kind of errors:
com.google.android.exoplayer2.upstream.HttpDataSource$InvalidResponseCodeExc
eption: Response code: 401
So, after 12h trying to reproduce the error we saw what's happening. If the
listener connection buffer due to anything, Icecast remove it's connection
and log the item bellow:
[2018-05-22 23:17:24] INFO source/send_to_listener Client 220977
(xxx.xxx.xxx.xxx) has fallen too far behind, removing
My question is:
1. Why Icecast need to do this?
2. Why the client can't reconnect?
3. The error 401 is when the client tries to reconnect and our auth
deny?
Best,
Thiago
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20180522/af53fa7a/attachment.html>
That answers question 1 but not 2 or 3.
From: Icecast [mailto:icecast-bounces at xiph.org] On Behalf Of Greg Ogonowski
Sent: Wednesday, 23 May 2018 2:42 p.m.
To: subscription at nextdial.com.br; 'Icecast streaming server user
discussions'
Subject: Re: [Icecast] Why "has fallen too far behind"?
"The man with two clocks knoweth not the time."
The audio source clock does not match the audio destination clock, and
sooner or later, something needs to "give." This causes buffer
under/over
flows.
The ICY protocol has no provision for timestamps which can be used to help
circumvent this in player clients, if supported.
HLS and DASH have this ability.
/greg.
StreamS
From: Icecast <icecast-bounces at xiph.org> On Behalf Of
subscription at nextdial.com.br
Sent: Tuesday, 22 May, 2018 18:46
To: icecast at xiph.org
Subject: [Icecast] Why "has fallen too far behind"?
Hello,
We are seeing in Firebase this kind of errors:
com.google.android.exoplayer2.upstream.HttpDataSource$InvalidResponseCodeExc
eption: Response code: 401
So, after 12h trying to reproduce the error we saw what's happening. If the
listener connection buffer due to anything, Icecast remove it's connection
and log the item bellow:
[2018-05-22 23:17:24] INFO source/send_to_listener Client 220977
(xxx.xxx.xxx.xxx) has fallen too far behind, removing
My question is:
1. Why Icecast need to do this?
2. Why the client can't reconnect?
3. The error 401 is when the client tries to reconnect and our auth
deny?
Best,
Thiago
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20180523/b8b55afa/attachment-0001.html>