listen.pls wrong IP address / admin page NG

[n1bsbri]

I'm having 3 issues. I've searched the forums, and read through many threads, but I haven't found one that looks like an answer for me.

I have Shoutcast 2 setup:


Win XP Professional SP3 32 bit
sc_serv.exe v2 0.0.19.0 2/25/11 (upgraded from earlier version which did the same thing)
sc_trans.exe v2 0.0.40.0 12/14/10

Both are on the same box, running as a service. I am using live capture on sc_trans from the sound card line in.

Problem #1:
The server plays from any computer on the LAN, using the local IP http://192.168.1.139:8000/listen.pls. When I test with an outside network to the public IP, http://n1bs.dyndns.ws:8000/listen.pls it does not work. Also does not work from the YP directory.

I have port forwarding configured in the router, and dyndns is being updated with the correct public IP. Here's the twist - the listen.pls file that is being sent to external listeners has the wrong IP address in the playlist! Looking at it with a text file (again this is from an external network), I get the following:

[playlist]
NumberOfEntries=1
File1=http://192.168.1.139:8000/ka1rci.mp3

I can't really see where that gets "programmed" for the correct address.

Problem #2:

http://192.168.1.139:8000 brings up gibberish. Same thing happens when accessing the public IP.

Partial paste:

ICY 200 OK icy-notice1:
This stream requires Winamp
icy-notice2:SHOUTcast Distributed Network Audio Server/win32 vFeb 25 2011
icy-name:KA1RCI Amateur Radio Network icy-genre:Misc icy-url:http://ka1rci.net content-type:audio/mpeg icy-pub:1 icy-br:48 ÿó`P
.¨\¬þ––¯ëè* ´}ÛUê™/;üä3Zd%6Í‹‡Ü²LÀ‚îÊ0„§0‚E¼À îÀp~dðžù_Jù,ó™¹~ÿkåU8HŘM–¥/Š§dü*¶Û’Km üÝOOt*


Problem #3

My log is filled with this - YP seems to list the station OK though.

2011-02-26 10:36:43 I msg:[YP2] Connecting to yp.shoutcast.com
2011-02-26 10:42:11 I msg:[DST 208.20.225.130:53729 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0
2011-02-26 10:42:11 E msg:[DST 208.20.225.130:53729 sid=1] Socket error while waiting to send data. err=Connection reset by peer.(10054)
2011-02-26 10:42:11 I msg:[DST 208.20.225.130:53729 sid=1] SHOUTcast 1 client connection closed (0 seconds) [Bytes: 41808] Agent: `Mozilla/5.0'
2011-02-26 10:46:44 I msg:[YP2] Connecting to yp.shoutcast.com
2011-02-26 10:52:11 I msg:[DST 208.20.225.130:54440 sid=1] SHOUTcast 1 client connection accepted. Mozilla/5.0
2011-02-26 10:52:11 E msg:[DST 208.20.225.130:54440 sid=1] Socket error while waiting to send data. err=Connection reset by peer.(10054)
2011-02-26 10:52:11 I msg:[DST 208.20.225.130:54440 sid=1] SHOUTcast 1 client connection closed (0 seconds) [Bytes: 41808] Agent: `Mozilla/5.0'

Any ideas welcome.

Thanks,
Brian

[n1bsbri]

One additional data point for problem #1:

On the listening client, if I edit listen.pls with notepad, and replace the local IP with the public address, it works fine from external network. In this case I save listen.pls and double click it on the listening computer. Still doesn't work accessing it from the server.

[playlist]
NumberOfEntries=1
File1=http://n1bs.dyndns.ws:8000/ka1rci.mp3

Brian

[Brutish Sailor]

If your having a socket error? Either somethings running on that port, or the port above it. Make sure what ever port your running on (IE 8000) has that port open dedicated for the server and has the next ports free (8001) If your running SC_serv on 8000, this could be the issue.

[n1bsbri]

Regarding problem #1, I changed sc_serv.conf and sc_trans.conf to use absolute addressing rather than relative, after reading a note about that. No change.

Does anyone know how the stream address gets loaded into listen.pls when it is generated? Why is my server plugging in the local IP address rather than the public address?

Brian

[DrO]

#1 - have you set destip or dstip in the config file. if so remove them. with the recent builds of the v2 DNAS, it will attempt to work out the ip / address from the connection attempt made to the listen.pls action and so fill it that way (apparently how the v1 DNAS did it from what i've been told). though there's nothing working in your posts that i can try to connect to inorder to see if my guess is correct or not.

#2 - you need to access /index.html to get to the status page as otherwise it's trying to play the stream in the browser.

#3 - that's from the above attempts to access the root of the stream in the browser.

-daz

[n1bsbri]

Hi Daz,

I did not have destip or dstip in the sc_serv configuration file. I thought I would add in the WAN address as a workaround, but when I do that sc_serv service starts then stops with the following in the log:

2011-03-01 20:17:36 I msg:<***> Logger startup
2011-03-01 20:17:36 I msg:<***> version 0.2.0.0 build 0.0.19.0
2011-03-01 20:17:36 D msg:<***>
2011-03-01 20:17:36 I msg:*******************************************************************************
2011-03-01 20:17:36 I msg:** SHOUTcast Distributed Network Audio Server (DNAS)
2011-03-01 20:17:36 I msg:** Copyright (C) 1999-2011 Nullsoft, Inc. All Rights Reserved.
2011-03-01 20:17:36 I msg:** Use "sc_serv filename.conf" to specify a config file.
2011-03-01 20:17:36 I msg:*******************************************************************************
2011-03-01 20:17:36 I msg:[SHOUTcast] DNAS/win32 v 0.2.0.0 b 0.0.19.0 (Feb 25 2011) starting up...
2011-03-01 20:17:36 I msg:[MAIN] PID: 2120
2011-03-01 20:17:36 I msg:[MAIN] Loaded config from c:\Program Files\SHOUTcast\sc_serv_brian.conf
2011-03-01 20:17:36 I msg:[MAIN] Calculated CPU count is 1
2011-03-01 20:17:36 I msg:[MAIN] Starting 1 network threads
2011-03-01 20:17:36 I msg:[MICROSERVER] Listening for connection on port 8000
2011-03-01 20:17:36 I msg:[MICROSERVER] Listening for connection on port 8001
2011-03-01 20:17:36 I msg:[MICROSERVER] Listening for connection on port 8000
2011-03-01 20:17:36 E msg:Error opening port 8000 because Could not bind to http://74.103.201.59:8000 because Address already in use.
2011-03-01 20:17:36 I msg:[MAIN] Terminating sources
2011-03-01 20:17:36 I msg:[MAIN] Waiting for final YP remsrvs
2011-03-01 20:17:36 I msg:[MAIN] Runner shutdown
2011-03-01 20:17:36 I msg:<***> Logger shutdown

sc_serv starts OK if I comment out destip, but of course I still have the other problem. By the way, problem #2 is good with what you said, I had forgotten about that.

Here is my config file. I have taken out the commented out lines for space. I have left the server up is you want to try again to access it. After the intro file you may hear dead air, that's normal, it's a scanner-type feed.

Thanks for the help Daz...

Brian


logfile=c:\Program Files\Shoutcast\logs\logfile.log

w3clog=c:\Program Files\Shoutcast\logs\sc_w3c.log
banfile=c:\Program Files\Shoutcast\control\sc_serv.ban
ripfile=c:\Program Files\Shoutcast\control\sc_serv.rip

yp2=1

publicserver=always
streamauthhash=12345678901234567890

portbase=8000

; manually set a destip as a workaround because DNAS is
; loading the wrong address into listen.pls
destip=http://74.103.201.59

password=fubar

adminpassword=differentfubar

buffertype=1
adaptivebuffersize=5

streamid=1
streampath=/ka1rci.mp3

Originally Posted by DrO

#1 - have you set destip or dstip in the config file. if so remove them. with the recent builds of the v2 DNAS, it will attempt to work out the ip / address from the connection attempt made to the listen.pls action and so fill it that way (apparently how the v1 DNAS did it from what i've been told). though there's nothing working in your posts that i can try to connect to inorder to see if my guess is correct or not.

#2 - you need to access /index.html to get to the status page as otherwise it's trying to play the stream in the browser.

#3 - that's from the above attempts to access the root of the stream in the browser.

-daz

[DrO]

that destip entry isn't right. it needs to just be the raw ip without the htp:// on the front.
other than that, it should just be working unless something is messing around with the handling internally. will try to reproduce the issue though i've not been able to get it to fail on any of my test setups so far.

-daz

[n1bsbri]

I tried the destip entry without http://, and it did the same thing (sc_serv started then stopped). It's commented out again and the server is running now.

Were you able to see what I was talking about with the listen.pls file?

Thanks again,
Brian

[DrO]

yeah am seeing http://192.168.1.139:8000/ka1rci.mp3 in the generated pls file. even when trying to access http://74.103.201.59:8000/listen.pls (was wondering if maybe it's something from using n1bs.dyndns.ws but doesn't seem to be) which is weird as there shouldn't be an attempt to provide a local ip when doing a remote connection.

at the moment i can either try to make a test build of the dnas to get a better idea of what is going on or if you've got some sort of access to the machine i could have then that will probably make it quicker for me to look into and try to see what the issue is (i.e. if it is in the DNAS or something else interfering with things).

-daz

[n1bsbri]

I'll set up a remote login for you, and I'll send you a PM. Thanks

[n1bsbri]

Hi all,

Just an update for closure on this one. I tried the SHOUTcast installation on another computer (Win7), and it worked fine. So that ruled out router / firewall / DDNS problems.

At that point, since I had reinstalled the SHOUTcast components twice, I figured the problem had to be in the OS. I took the drastic step of reinstalling WinXP SP3 and rebuilding the server.

And the good news is: it works now. The bad news: I still don't know what the original problem was, but I don't care so much now.

Thanks DrO for the help.

Brian

[DrO]

rightio, had been wondering what was going on as things had gone quiet. i have made a few changes for the next drop to hopefully make it a bit more reliable either way though is good to know that it's otherwise working ok. will scrub it off my todo list

-daz

[dicion]

I am currently having this exact same problem right now...

Server is here:
http://radio.everfreeradio.com:5800/index.html?sid=1

If you open the listen.pls from the 'Listen' Link, you'll see the playlist entry it contains points to a completely different IP address than the one it should.

Was working fine until this morning, no idea why it picked up that random IP that it's handing out in listen.pls, it's not an IP on the server it's running on at all...

I just downloaded this DNAS yesterday, so it's the most current version.

[DrO]

the IP for that part is determined based on what the DNAS can work out from the request made to access it. if it was working beforehand then something external of the DNAS (possibly what it is running on or where in the network) has changed.

the easiest option is to specify the external IP/address using the 'destip' config option e.g. destip=radio.everfreeradio.com (or the IP of it) and see if that works as something is obviously messing with the DNAS trying to work things out now.

-daz

[dicion]

I managed to fix it by setting a dstip= as specified above, but I also had to re-specify the srcip as 127.0.0.1 (for sc_trans) or else it would try to duplicate the 5800 port on the same IP, say it cant open it twice, and crash.

Still very odd, no idea where it got that last IP from.

[DrO]

yeah, bit strange on the other IP but as long as the destip option is working then that's the main thing (as seems to from a quick try).

the srcip thing for sc_trans is a bug i fixed 2 days ago in sc_trans but haven't released a fixed version yet.

-daz

[dicion]

I think I may have found the origin of this problem, but I have not had time to reproduce it.

In my case, I believe it was because the hostname of the machine the dnas was running on, was unresolvable (I have since changed it to a properly resolvable name to the machine's IP, but have not removed dstip to test if it fixes it). Normally this wouldn't be a problem, because a non-resolvable name should be non-resolvable, give an expected failure to resolve, and just fall back to ip. This is how DNS is supposed to work.

However, the provider my server is through apparently uses OpenDNS as their DNS provider. OpenDNS has a DNS redirector for non-resolvable hostnames (it can be disabled, but apparently they did not do so). Eg, if it would normally be a non-resolvable hostname, instead of simply failing to resolve, it resolves to OpenDNS's search server, and gives you search results for that domain when you go there via http.

The IP my listen.pls was pointing to, turned out to be the ip of OpenDNS's search server. *headdesk*

So.... if you're getting the wrong IP in your listen.pls, enter the following command on which sc_serv is running:

host $HOSTNAME

If it returns any IP address other than an IP of the server, or an NXDOMAIN Error, that could be the cause of your problem. Solutions are as follows:

- use dstip
- change to a dns server/service that does not resolve non-resolvable names
- change your hostname to a name that properly resolves to the server's ip address.


Hopefully this helps someone in the future!

[DrO]

thanks for that dicion, will keep a note of it incase it appears for other people.

-daz

[materman]

Hey guys. I don't know if this helps or not but I've just recently had the same problems as posted on here. With the older v1.9.8 DNAS I could simply create a listen.pls link on my webpage and people could click on it and it would open the public ip up for them in their default player. With the v2.0 you cannot do this. When you click on the webpage link it includes the local ip address. If you choose to save the listen.pls link as a file and open it with notepad it shows:

[playlist]
NumberOfEntries=1
File1=http://192.168.1.101:8000/stream/1/
Title1=Back to the Farm Hour
Length1=-1
Version=2

Whereas the older 1.9.8 version only shows:

[playlist]
NumberOfEntries=1
File1=http://my public ip address:8000/

When people get redirected with the older version it works, but with the new version the DNAS includes the local ip where the server is located. I've even tried to do the "dstip" or "destip", but the DNAS just crashes immediately. Is there a workaround at this point?

[materman]

Okay. I did a little searching after I posted before and found a post for "listen" at:

http://forums.winamp.com/showthread.php?t=338666

I can understand perfectly what you are saying DrO, but I'm just a little confused about why v1's listen.pls works fine for me but if I install v2 and go to the admin page on a computer outside my local network (client) then the local url for my streaming computer takes precedence. Even if I type in my wan url in the streampath= all it does is place that url after the lan url. DestIP= doesn't seem to work. I even tried to distinguish the SrcIp= from the DestIP= so that maybe the server wouldn't be confused:

SrcIP=http://192.168.1.101
DestIP=http://<my wan ip>

But the server just closes. I've tried it with and without the http:// and even tried putting the port on the end in all different combinations. I wish you could reproduce this. If the v1 operates correctly then the only thing logical to deduce would be that there is something that changed from the v1 build to the v2 build. Something in v2 must not be resolving the ip the way v1 did.

Just a little input here. I'm no expert by no means but I just thought maybe this info would help.

materman

[DrO]

first thing, srcip has no effect on this so am going to ignore anything about that option.


with the whole destip aspect, as i've not been able to replicate the issue some people are seeing, i'm not too sure why / what is going on to cause the IP to be set to a lan IP despite being made from a non-lan connection.

since both the v1 and v2 DNAS (after looking at the v1 source code which is massively different to the v2 source code) will attempt to get the 'host' header on the client connection and just uses that. so either something else is going on which the v1 DNAS never noticed or the v2 DNAS is more susceptible too or there is a legit bug in the v2 DNAS but as i'm not able to replicate and debug logs haven't been to helpful, i'm not sure there's much i can do to resolve the issue at the moment.


one thing i have provisionally added to the v2 DNAS (and works in conjunction with some YP side changes) is to have the YP return back the public IP of DNAS and for it to use that if available. obviously it won't help if the DNAS is not publically listed but its something for the main usage of the DNAS.

-daz

[DrO]

(bit of a necro bump but am replying so i can clear out my pending threads list)

the cause of the issue with the wrong IP being used for /listen.pls stems from the code which binds to the required ports on starting up. unfortunately with the public build of the v2 DNAS, setting destip may not work as expected leading to things like fatal bind errors, etc.

along with the change mentioned in my prior reply about making use of the public IP as determined by the YP, using destip should work as expected with prior bind related errors being changed to warnings and alternative handling put in place to allow destip to be used as expected (which then helps the non-listed scenario).

additionally force setting destip=any will enable the behaviour mentioned as well and should be able to be used for those using the current public build (b29) as a work around in the interim.

-daz

[babisbabis]

Hi.
This s my first post here

Unfortunately the same issue (listen.pls points to local IP) happens here, too...
Do we have any news about it?
destip=any doesn't make difference.
Also destip=<the right IP> causes the server to stop.

One last question:
streampath=?? what should we put there? I noticed that it affects the path that listen.pls points to.
For example, if i put udmfm.dyndns.org then the listen.pls points to: <local IP>/udmfm.dundns.org .
Unfortunately the <local IP> remains...

P.S. WinXP, DNAS build 29

Regards,
Babis.

[DrO]

Originally Posted by babisbabis

Unfortunately the same issue (listen.pls points to local IP) happens here, too...
Do we have any news about it?

you'll need to wait for the next DNAS update (as i've only gotten the required YP update needed to facilitate the DNAS fix deployed as of friday) which will allow doing destip=udmfm.dyndns.org and that will work as expected. the usage of the local IP stems from how destip is handled if specified as 'any' or just not specified at all - since it basically pulls the host details from the machine in some cases.

Originally Posted by babisbabis

streampath=?? what should we put there? I noticed that it affects the path that listen.pls points to.
For example, if i put udmfm.dyndns.org then the listen.pls points to: <local IP>/udmfm.dundns.org .
Unfortunately the <local IP> remains...

streampath is just for how to access the stream or to brand it as more obvious for the format it is e.g. streampath=mobile would allow for <server>:<port>/mobile in the listen.pls link.

if not specified then generally it will default to /stream/x/ (where x is the stream #) or / (for stream #1 depending on the build of the DNAS being used. this is all covered in the documentation.

-daz

[babisbabis]

Hi DrO

Thank you very much for the reply
I will wait for the next DNAS update then.

Babis.

[e-j]

Excuse the necromancy, but I'm experiencing the same IP resolution issue n1bsbri described. Is this still bugged in the latest DNAS?

The listen.pls generated from the DNAS points to my SHOUTcast server's private IP rather than the public. If I manually edit the listen.pls or open the URL directly through an audio player I'm able to connect to the stream. Adding destip=any makes no difference. Changing destip= to my public hostname or IP causes the DNAS to shutdown with the following error:

code:
2013-01-11 13:20:46     E       msg:Error opening port 8000 because Could not bind to subfocus.dance.fm:8000 because Address already in use.

What does this mean exactly? I am 100% positive that no other application is bound to port 8000. Does anyone know the method the DNAS uses to determine the host's public IP address?

Environment:

Windows XP Pro SP3 32-bit
SHOUTcast Server v2.0.0.29/win32
Winamp source DSP 2.3.2 build 190

Configuration file:

code:
password=***

adminpassword=***

requirestreamconfigs=1

logfile=C:\Program Files\SHOUTcast\sc_serv.log

w3clog=C:\Program Files\SHOUTcast\sc_w3c.log

publicserver=always

banfile=C:\Program Files\SHOUTcast\sc_serv.ban

ripfile=C:\Program Files\SHOUTcast\sc_serv.rip

streamid=1

streamauthhash_1=***

[DrO]

since there's not been a new public build since the last posts in this thread, it still is a present issue as it's the same build being referenced.

everything you've described is known not to work / provide the value as expected and currently any use of 'destip' will not work in a reliable manner so until the newer DNAS build is released (again no eta) then you should not use that configuration option - as it's a combination of issues which are causing your playlist problems.

-daz