This has happened with about 5 accounts so far, for some reason, unknown why but it seems like several different, unrelated actions cause this, but the stream will not restart, does not display a error just does not play any more, the only solution is to change the port #

So far problem has only happened with SHOUTcast v2

Could you please explain the exact steps to reproduce this?  (If several unrelated actions cause it, please give one or two examples.)  Does it only happen upon clicking "restart", or does it also happen upon clicking "stop", then "start"

Also please explain what you see on the ShoutCast DNAS admin page when this happens, what (if anything) is in the Shoutcast error log at the time of this happening, and exactly how it "just does not play any more" -- eg: if it doesn't play, you must get an error message when you try to tune in, yes?  If so, what is it?  And what does the ShoutCast error log say at the time of the attempted tune-in?

Yes that is the problem also there is no error displayed, nothing - just blank stream, but as I said this has only happened a couple times the first I did not really look for a error code and by the time I caught the latest one several days had passed so I could not really find anything in the log, but I do know that the ports this happens on no longer work, I can try to recreate a new account on a older, problem port and the same thing happens, nothing.

I have sent u a PM with the server info if you wanna take a look, subject is Port Problem

For me that happend few times too.

Last time I have received email form CC panel that stream crashed but was restarted succesfully but when I logged in to panel it was looks like autodj is not working but stream was playing.
After try to restart autodj I had message in logs about that sorce can't connect because port is busy.
There was just one way to do this, kill proccess from console.

Mine seems to be getting worse, now once every few days all streams will just stop, I must run /etc/init.d/centovacast restart and all streams restart and  are fine for a while then it happens again in a day or 2.

Could you please explain the exact steps to reproduce this?  (If several unrelated actions cause it, please give one or two examples.)  Does it only happen upon clicking "restart", or does it also happen upon clicking "stop", then "start"

Also please explain what you see on the ShoutCast DNAS admin page when this happens, what (if anything) is in the Shoutcast error log at the time of this happening, and exactly how it "just does not play any more" -- eg: if it doesn't play, you must get an error message when you try to tune in, yes?  If so, what is it?  And what does the ShoutCast error log say at the time of the attempted tune-in?

I do not know I am usually asleep when it happens, I wake up and the entire server is down, however since I have removed some streams it happens less but I still have to restart the server at least once every 2 days,

more accounts = more problems, the few accounts I do have on there get a lot of listeners (listed in iTunes) may have something to do with it and be the reason no one else has the problem, but I suspect once they start getting hundred+ listeners it may happen to them too

The only log is the one I provided above, and it shows the same thing each time this happens. Since the entire server goes down I cannot see any live errors other than that. Page not found is all I see till I restart the VPS

I do not know I am usually asleep when it happens, I wake up and the entire server is down, however since I have removed some streams it happens less but I still have to restart the server at least once every 2 days,

Sorry, I'm lost.  The initial topic of this thread was an issue wherein clicking 'Restart' would cause the streaming server to stop responding until you changed the port number.  All of my questions in this thread were in regard to that issue.  And by "the ShoutCast DNAS admin page" I mean the admin page for ShoutCast DNAS at http://ip:port, not Centova Cast.  And by "ShoutCast error log" I mean the actual ShoutCast error log at /usr/local/centovacast/var/vhosts/username/var/log/error.log, not the Centova Cast event log.

The situation you're describing in your most recent post (cc-control going down and Centova Cast itself becoming unreachable) is an entirely different issue altogether.  I would again recommend checking the logs (again, not the event log -- the logs in /usr/local/centovacast/var/log) to find out what happened there.  But for clarity that would be better dealt with in a separate forum topic.

still trying to pinpoint when the problem is happening ,I do know there is something the user is doing to cause it to restart,  but for now here are some of the error logs - one is so big I didn't even try to download it, it's almost the size of a movie (see screenshot) -- could the fact they are so big be a reason I am star
ting to have problems, doesn't it get harder and harder for it to write to the file as they get bigger and bigger?


/usr/local/centovacast/var/cc-appserver.log (hundreds of lines dating back to last month

[22-Jul-2012 01:20:05 UTC] PHP Warning:  gmmktime() expects parameter 6 to be long, string given in /usr/local/centovacast/system/servers/ShoutCast2/class_ServerShoutCast2.php on line 281

-------------------------------------------------------------------------------------

/usr/local/centovacast/var/cc-web.log (this is huge, 38 MEG) (all lines are the same, dating back to last month) (IP address digits hidden by me)

2012/07/22 01:27:32 [error] 16529#0: *30005 readv() failed (104: Connection reset by peer) while reading upstream, client: 173.###.###.34, server: centovacast, request: "POST /nextsong.php HTTP/1.1", upstream: "fastcgi://unix:/usr/local/centovacast/var/run/cc-appserver.sock:", host: "173.###.###.34"

-------------------------------------------------------------------------------------

/usr/local/centovacast/var/cc-web_access.log (303 MEG) -- this is after a month

-------------------------------------------------------------------------------------

/usr/local/centovacast/var/control/masterlog.log (52.39M) -- thousands of the same line below back to June 11

[22/Jul/2012:01:34:50 +0000]  child process 22473 exited with status 0

I am also having the same issue, what i found that there is a clash between sc_server and sc_trans ports, if we use random port selection and create multi users it assign the ports with the gap of 4 like 1st user 5012 ,  2nd  5016, 3rd 5020 etc, i found that sc_trans of 2nd user using the ports 5018,5020,5021. It were using the same port i.e 5020 which system assigned for 3rd user, I changed the port manually from source.conf to fix this issue.

one is so big I didn't even try to download it, it's almost the size of a movie (see screenshot)

No worries, that's just the access log for the control panel, that won't contain any error information anyway.  We should probably implement log rotation for those files though -- thanks for pointing that out.

doesn't it get harder and harder for it to write to the file as they get bigger and bigger?

No, file size has no impact on write speed.

/usr/local/centovacast/var/cc-appserver.log (hundreds of lines dating back to last month

[22-Jul-2012 01:20:05 UTC] PHP Warning:  gmmktime() expects parameter 6 to be long, string given in /usr/local/centovacast/system/servers/ShoutCast2/class_ServerShoutCast2.php on line 281

Hmm, hundreds of them?  In a nutshell, that means your ShoutCast2 server's access log file has something foul where Centova Cast expects to find the year, i.e.: the format of scserv2 log files is something like:

Code: [Select]

1.2.3.4 1.2.3.4 2012-07-21 16:23:17 /stream?title=Unknown 200 Useragent 356032 6 474709

The error you quoted says that where Centova Cast expected to find "2012" in the above line, it found text instead.  Possibly a bug, but more likely there's bad data being written to your var/vhosts/USERNAME/var/log/access.log.

2012/07/22 01:27:32 [error] 16529#0: *30005 readv() failed (104: Connection reset by peer) while reading upstream, client: 173.###.###.34, server: centovacast, request: "POST /nextsong.php HTTP/1.1", upstream: "fastcgi://unix:/usr/local/centovacast/var/run/cc-appserver.sock:", host: "173.###.###.34"

Further hmm.  Do all of these lines show "request: POST /nextsong.php", or is there a variety of different requests?  Basically this is saying that PHP unexpectedly stopped returning data to the web server in the middle of a request.  If it's just for /nextsong.php then the problem is probably to do with nextsong.php... if it's for a variety of requests, then there's likely some kind of compatibility issue with our PHP build on your server that's causing PHP to segfault.

/usr/local/centovacast/var/cc-web_access.log (303 MEG) -- this is after a month

That just means you have a lot of people accessing Centova Cast.  That's a good thing.   But again, we'll get some log rotation in there before the production release.

[22/Jul/2012:01:34:50 +0000]  child process 22473 exited with status 0

The "status 0" means "no problems, everything worked as expected" so that's all good.

Appreciate you sending the above, and certainly some weirdness there, but nothing that would cause ShoutCast2 to restart.  And FYI this still isn't what we need to diagnose the original issue.   As I mentioned previously, if ShoutCast2 itself is restarting, you will only find the details in the ShoutCast2 error logs.  To be explicit, that's /usr/local/centovacast/var/vhosts/USERNAME/var/log/error.log. 

I am also having the same issue

Yours is actually a completely different and unrelated issue.

what i found that there is a clash between sc_server and sc_trans ports

Correct, and good diagnosis, but this has already been reported in another thread and fixed for the next build.

Steve: one thing to note is that My Auto DJ has been using a newer v2 DNAS compared to the public build so that might be causing some of the issues (though that was done a month back to resolve other issues which were being seen due to DNAS bugs).

-daz