[Icecast] Clients, not always connecting since about 2.4.1, 2.4.2.

[Gavin Stephens]

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