Gavin Stephens
2020-May-22 18:22 UTC
[Icecast] Clients, not always connecting since about 2.4.1, 2.4.2.
Hi Philip,
I'll do more testing and logging over the weekend and see how I go.
At the moment I have 2.4.4 Win32 running on port 9000 @
http://radioinvercargill.nz:9000/ I'm not sure how good this will be from
overseas as the queue is only about 8 seconds, burst about 4 seconds. It's
adequate for xDSL/Fibre and 4G mobile over here and is on a 450Mbps upstream
fibre line. I've tried lower bursts and much bigger queues and visa versa
but it's a 288Kbps stream so the burst needs to be quite high to avoid any
stuttering for the Muses web player while initially connecting. The only change
to the config file is limit section:
<limits>
<sources>10</sources>
<workers>10</workers>
<clients>250</clients> (because the server is on a
100Mbps port)
<queue-size>589824</queue-size>
<burst-on-connect>1</burst-on-connect>
<burst-size>294912</burst-size>
</limits>
I'll adjust the logging level in a moment and do more tests.
I have kh8 running on port 8000 while I test a few things out more with 2.4.4 on
9000. I can't remember which version of Icecast I was using when I first
started noticing these odd weird connects. I'll have to keep rolling back
until it goes away again, it was earlier on in 2.4.x or just before it. I
initially switched to kh the first time I struck it earlier on in 2.4.x I think,
or just before 2.4. Then came back to 2.4.2 recently and on to 2.4.4 but the odd
failed connections still persisted even on the LAN, changed switch port, cable,
Ethernet adapter etc...
However some developments tonight: In VLC when the initial connection hangs, the
network monitor on the test client machine shows the traffic is still moving at
288Kbps (the stream bitrate). The same thing happens from my mobile phone
though. This would suggest VLC is the issue, yet it only does this with 2.4.4
not kh8. The connection doesn't finish to the point audio starts in VLC or
the duration timer starts. About every handful of connects. In Muses player
though, it simply reports Network Error now and then while trying connect (even
on the LAN), disconnects and re-tries in 10 seconds or so. The test Muses player
for the 2.4.4 server is this page http://radioinvercargill.nz/index4.htm Both of
these maybe client issues and nothing to do with each other either (I need to
keep that in mind). The normal website index page is currently using kh8 on port
8000.
I don't know if this observation has anything to do with it either: The port
8000 server (kh8) bursts it's traffic very high on initial connection. From
Icecast 2.4.4 server on port 9000, the burst in-house on the same LAN is much
lower, not much more than the stream rate and over a longer period, about 4-5
seconds before the stream rate stabilises @ 288, so I wonder if this is why VLC
or Muses is acting strange on some connects. I'll roll back a few Icecast
server versions to maybe 2.3.x and do some burst speed observations again on the
LAN. When it connects here it runs fine, no hick-ups not even from my 4G mobile
on data, although I'll be using a lower rate for mobile phones soon. Great
quality and reasonably low latency for online within N.Z.
=====================
Good morning,
On Thu, 2020-05-21 at 03:49 +1200, Gavin Stephens wrote:>/I can confirm it doesn't happen on kh13 Win32 build either. I think it
/>/was introduced about 2.4.1/2 in the normal version. /
First of all, please note that there is no such thing as a "kh
branch".
The Icecast-kh software is a different software by a different vendor.
It's not part of the Icecast project. Also it can hardly compared to
Icecast when it comes to bugs as the codebase is a different one.
About your problem:
I'm not aware of anything like this. What is the error returned by the
player? what is in the access.log and the error.log about those connect
attempts?
Also, is your stream publicly accessible? Would allow us to have a look
and maybe find something.
It might also be wise to post your config file with *only* the passwords
removed.
With best regards,
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20200523/31072e49/attachment.html>
Gavin Stephens
2020-May-22 18:28 UTC
[Icecast] Clients, not always connecting since about 2.4.1, 2.4.2.
...and of course, password and host. Everything else is the same in the config. On 23/05/2020 6:22 am, Gavin Stephens wrote:> Hi Philip, > > I'll do more testing and logging over the weekend and see how I go. > > At the moment I have 2.4.4 Win32 running on port 9000 @http://radioinvercargill.nz:9000/ I'm not sure how good this will be from overseas as the queue is only about 8 seconds, burst about 4 seconds. It's adequate for xDSL/Fibre and 4G mobile over here and is on a 450Mbps upstream fibre line. I've tried lower bursts and much bigger queues and visa versa but it's a 288Kbps stream so the burst needs to be quite high to avoid any stuttering for the Muses web player while initially connecting. The only change to the config file is limit section: > > <limits> > <sources>10</sources> > <workers>10</workers> > <clients>250</clients> (because the server is on a 100Mbps port) > <queue-size>589824</queue-size> > <burst-on-connect>1</burst-on-connect> > <burst-size>294912</burst-size> > </limits> > > I'll adjust the logging level in a moment and do more tests. > > I have kh8 running on port 8000 while I test a few things out more with 2.4.4 on 9000. I can't remember which version of Icecast I was using when I first started noticing these odd weird connects. I'll have to keep rolling back until it goes away again, it was earlier on in 2.4.x or just before it. I initially switched to kh the first time I struck it earlier on in 2.4.x I think, or just before 2.4. Then came back to 2.4.2 recently and on to 2.4.4 but the odd failed connections still persisted even on the LAN, changed switch port, cable, Ethernet adapter etc... > > However some developments tonight: In VLC when the initial connection hangs, the network monitor on the test client machine shows the traffic is still moving at 288Kbps (the stream bitrate). The same thing happens from my mobile phone though. This would suggest VLC is the issue, yet it only does this with 2.4.4 not kh8. The connection doesn't finish to the point audio starts in VLC or the duration timer starts. About every handful of connects. In Muses player though, it simply reports Network Error now and then while trying connect (even on the LAN), disconnects and re-tries in 10 seconds or so. The test Muses player for the 2.4.4 server is this pagehttp://radioinvercargill.nz/index4.htm Both of these maybe client issues and nothing to do with each other either (I need to keep that in mind). The normal website index page is currently using kh8 on port 8000. > > I don't know if this observation has anything to do with it either: The port 8000 server (kh8) bursts it's traffic very high on initial connection. From Icecast 2.4.4 server on port 9000, the burst in-house on the same LAN is much lower, not much more than the stream rate and over a longer period, about 4-5 seconds before the stream rate stabilises @ 288, so I wonder if this is why VLC or Muses is acting strange on some connects. I'll roll back a few Icecast server versions to maybe 2.3.x and do some burst speed observations again on the LAN. When it connects here it runs fine, no hick-ups not even from my 4G mobile on data, although I'll be using a lower rate for mobile phones soon. Great quality and reasonably low latency for online within N.Z. > > > =====================> > > Good morning, > > > On Thu, 2020-05-21 at 03:49 +1200, Gavin Stephens wrote: > >/I can confirm it doesn't happen on kh13 Win32 build either. I think it />/was introduced about 2.4.1/2 in the normal version. / > First of all, please note that there is no such thing as a "kh branch". > The Icecast-kh software is a different software by a different vendor. > It's not part of the Icecast project. Also it can hardly compared to > Icecast when it comes to bugs as the codebase is a different one. > > > About your problem: > I'm not aware of anything like this. What is the error returned by the > player? what is in the access.log and the error.log about those connect > attempts? > > Also, is your stream publicly accessible? Would allow us to have a look > and maybe find something. > > It might also be wise to post your config file with *only* the passwords > removed. > > With best regards, > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > Virus-free. www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200523/8e1bc3ad/attachment.html>
Gavin Stephens
2020-May-23 08:22 UTC
[Icecast] Clients, not always connecting since about 2.4.1, 2.4.2.
Does anyone know what the max burst size is in 2.4.4? After installing some traffic flow filters on my router I can see that 2.4.4 is not bursting the 4 seconds I'm asking it too @288Kbps. I think this is where the initial connection problems are happening. On 23/05/2020 6:28 am, Gavin Stephens wrote:> > ...and of course, password and host. Everything else is the same in > the config. > > On 23/05/2020 6:22 am, Gavin Stephens wrote: >> Hi Philip, >> >> I'll do more testing and logging over the weekend and see how I go. >> >> At the moment I have 2.4.4 Win32 running on port 9000 @http://radioinvercargill.nz:9000/ I'm not sure how good this will be from overseas as the queue is only about 8 seconds, burst about 4 seconds. It's adequate for xDSL/Fibre and 4G mobile over here and is on a 450Mbps upstream fibre line. I've tried lower bursts and much bigger queues and visa versa but it's a 288Kbps stream so the burst needs to be quite high to avoid any stuttering for the Muses web player while initially connecting. The only change to the config file is limit section: >> >> <limits> >> <sources>10</sources> >> <workers>10</workers> >> <clients>250</clients> (because the server is on a 100Mbps port) >> <queue-size>589824</queue-size> >> <burst-on-connect>1</burst-on-connect> >> <burst-size>294912</burst-size> >> </limits> >> >> I'll adjust the logging level in a moment and do more tests. >> >> I have kh8 running on port 8000 while I test a few things out more with 2.4.4 on 9000. I can't remember which version of Icecast I was using when I first started noticing these odd weird connects. I'll have to keep rolling back until it goes away again, it was earlier on in 2.4.x or just before it. I initially switched to kh the first time I struck it earlier on in 2.4.x I think, or just before 2.4. Then came back to 2.4.2 recently and on to 2.4.4 but the odd failed connections still persisted even on the LAN, changed switch port, cable, Ethernet adapter etc... >> >> However some developments tonight: In VLC when the initial connection hangs, the network monitor on the test client machine shows the traffic is still moving at 288Kbps (the stream bitrate). The same thing happens from my mobile phone though. This would suggest VLC is the issue, yet it only does this with 2.4.4 not kh8. The connection doesn't finish to the point audio starts in VLC or the duration timer starts. About every handful of connects. In Muses player though, it simply reports Network Error now and then while trying connect (even on the LAN), disconnects and re-tries in 10 seconds or so. The test Muses player for the 2.4.4 server is this pagehttp://radioinvercargill.nz/index4.htm Both of these maybe client issues and nothing to do with each other either (I need to keep that in mind). The normal website index page is currently using kh8 on port 8000. >> >> I don't know if this observation has anything to do with it either: The port 8000 server (kh8) bursts it's traffic very high on initial connection. From Icecast 2.4.4 server on port 9000, the burst in-house on the same LAN is much lower, not much more than the stream rate and over a longer period, about 4-5 seconds before the stream rate stabilises @ 288, so I wonder if this is why VLC or Muses is acting strange on some connects. I'll roll back a few Icecast server versions to maybe 2.3.x and do some burst speed observations again on the LAN. When it connects here it runs fine, no hick-ups not even from my 4G mobile on data, although I'll be using a lower rate for mobile phones soon. Great quality and reasonably low latency for online within N.Z. >> >> >> =====================>> >> >> Good morning, >> >> >> On Thu, 2020-05-21 at 03:49 +1200, Gavin Stephens wrote: >> >/I can confirm it doesn't happen on kh13 Win32 build either. I think it />/was introduced about 2.4.1/2 in the normal version. / >> First of all, please note that there is no such thing as a "kh branch". >> The Icecast-kh software is a different software by a different vendor. >> It's not part of the Icecast project. Also it can hardly compared to >> Icecast when it comes to bugs as the codebase is a different one. >> >> >> About your problem: >> I'm not aware of anything like this. What is the error returned by the >> player? what is in the access.log and the error.log about those connect >> attempts? >> >> Also, is your stream publicly accessible? Would allow us to have a look >> and maybe find something. >> >> It might also be wise to post your config file with *only* the passwords >> removed. >> >> With best regards, >> >> >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >> Virus-free. www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >> >> >> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >> _______________________________________________ >> 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-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200523/3e8c97fc/attachment.html>