Shoutcast 2.0 stats file read by python pauses for 5 sec each read

[ProducerMike]

I'm writing some simple python code to read the stats.xml file from a Shoutcast 2.0 server which I have on a test network. Each time the python script attempts to read the file it pauses for 5 seconds.

Python 2.6.5 on Ubuntu or Python 2.7.3 on Raspberry Pi Shoutcast 2.0.0.29 on Windows 7 - 64Bit

Using Urllib2

code:
import urllib2

statsfile = urllib2.urlopen('http://10.46.0.43:8000/stats?sid=1')

This will read the file but causes a 5 second pause in program execution. Almost like a timeout. I have tried this on both a raspberry pi and also a Ubuntu box. The same happens if I run it as a python program or entering commands in the python cli.

The stats.xml is correctly read and transferred it's just the pause that's causing the problem.

I have also copied the stats.xml file to an IIS server and the python script runs fine reading the file from there.

I have also tried urllib.urlretrieve which produces the same result.

This is on a small test network so I don't believe it is bandwidth. I am using a IP address to rule out DNS issues. It is 100% reproducible. I have rebuilt the Windows 7/Shoutcast server and am still getting the issue.

Any good ideas, anyone?

Thanks in advance

ProducerMike

[DrO]

firstly, i'd suggest updating to the current version (2.4.2) than using 2.0 as a lot has changed between them and if there is an issue, we can only really do things against a current DNAS version.

if it still happens then there's a few things which i can think off, though it can really depend on the load at the time as to how well (or not) the DNAS may take to respond to such requests (which even with some of the caching as done, won't help in all cases).

[ProducerMike]

Ok, so I updated the ShoutCast installation to 2.4.2.167 and I am still experiencing the same problem.

Next steps will be to bring it down to a 32-bit installation on Windows 7 and possibly XP.
I might also try building a Linux box and installing ShoutCast on there.

As I have been able to reproduce the problem on both a Ubuntu install on a PC and a Raspberry Pi - I'm really looking at the ShoutCast installation as being the root of the problem.

If anyone could try and reproduce my results I would be most grateful.

At the moment all of this testing is taking place on a 'internal' network, with both machines on the same subnet, with only the products mentioned installed on the machines. I have stripped everything back to as basic as possible.

ProducerMike

[DrO]

can you try enabling all of the debug options supported by the DNAS and either pm me a link to the log dump (and also a copy of the settings without passwords) or send both bits to my user name @shoutcast.com.

also you've not mentioned what the listener load is at the time as high numbers of listeners could lead to a slower response time on that method, but i've only seen it when running well over 1000 clients.

also have you increased the ulimit - n value used for the setup over 1024 ? as that has in the past caused some people issues with how the DNAS responds (or rather doesn't).

[Colin2]

If the namelookups option is enabled in sc_serv.conf, the Windows version of DNAS performs slow NetBIOS computer name lookups for LAN IP addresses.

[DrO]

until configs & logs are seen, we're just going to be guessing as to what is the cause.

[edit]
another thing to try is to see if it's slow when accessing it directly via a browser and not use the python method. the link is also provided on the server admin summary page (admin.cgi?sid=0) at the bottom right of the stream info block shown.

[jaromanda]

Originally Posted by ProducerMike

I might also try building a Linux box and installing ShoutCast on there.

No need to build a Linux box, you have an Ubuntu install and a raspberry pi already, either of those will run DNAS just fine

Originally Posted by ProducerMike

As I have been able to reproduce the problem on both a Ubuntu install on a PC and a Raspberry Pi - I'm really looking at the ShoutCast installation as being the root of the problem.

As far as I can tell, you've proved that the problem exists either with
* DNAS in windows, or (just as likely)
* urllib2.urlopen function in Linux

I've opened (in a browser) ...../stats?sid=1 on a DNAS running in windows 7 64bit ... the response was immediate, no delays - so there is no inherent delay in reading that resource when DNAS is on Windows 64bit

[jaromanda]

Originally Posted by DrO

also have you increased the ulimit - n value used for the setup over 1024 ? as that has in the past caused some people issues with how the DNAS responds (or rather doesn't).

Would that be on the DNAS machine or the client machine running Python? If the former, there is no ulimit command in wondoze (or is there?)

[DrO]

ignore me, i'd read things at the start wrong and kept thinking it was a *nix setup.