What I have found...
The way the new yp listing works is fairly straightforward...When the SC_SERV goes to list your broadcast it makes a call to addsrv (yp.shoutcast.com/addsrv) and passes it all your broadcast info (title, genre, etc) *and* the port number (of the locally running SC_SERV). Addsrv (CGI script) then turns around and determines where the request came from (getenv("REMOTE_ADDR")) and then does a connect on that IP at the port specified in the request. If it cannot connect, then you get the connection refused error back from the yp_add, if it does connect and does not find a valid shoutcast stream (I think it looks for 2 things, first, an ICY 200 OK return *and* 8192 bytes of valid mp3 data - within a 10 second period of time). If it does not find a valid shoutcast stream, you get the 404 error.
So, you might ask, why is it not working ?
Most problems I have seen so far with regards to the listing have come from people who are behind proxies (some didn't know they were) or using NAT devices such as bandwidth sharing gizmos (linksys, etc)...
Try the following :
From a machine *outside* your internal network try to connect to the IP
ort of what you think is your externally accessible IP
ort is and send it a GET request, either telnet to it and send a :
GET / HTTP/1.0
or use lynx...And make sure you are doing this from outside your NAT configuration.
If it seems to be working, then from your broadcast machine (behind your NAT device) goto : http://www.oddsock.org/test/wherefrom.php3
This will tell you where yp.shoutcast.com *thinks* your request is coming from. Is this the same as what you thought ?
If all of this checks out and yet you are still not being listed, then it is *possible* (although unlikely) that the yp.shoutcast servers are so overloaded that they cannot connect to and recieve the 8192 bytes of mp3 data within the 10 second timeout.
sorry if I restated/overstated things...