Statics Reports Not working after last update Version number   3.1.0.20140826.321r2889

same problem

same problem for all my stations

Support told me that I have the latest version with the fix but I will need to run a script via SSH but for some reason does not work on centos.


"This was due to a bug we've just recently discovered and released an update to fix it. Your version already includes the fix but you need to do the following:

The following commands should restore the stats for the last 48 hours:

for f in /usr/local/centovacast/var/vhosts/*/sc_w3c*.log; do n=${f/sc_w3c_/var\/log\/access.log.}; n=${n%.log}; n=${n/sc_w3c/var\/log\/access.log}; mv $f $n; done

/usr/local/centovacast/bin/ccmanage cronjob --job=logrotate,logprocess


Furthermore you would need to update every station's configuration (you don't actually have to make any modification, just press the update button) and restart the station before things start working correctly again."

Hello guys has the issue been sorted with the non statistics report not showing yet or how can I fix the issue

HI,

no, looks like we have this problem after the last update and centova is on vacation on labor day weekend.
  I guess they will come with a faster solution if they start to receive support tickets with the same problem so people start to open support tickets.

After have runned the script, the problem persists, for all my stations.

I was also instructed to update the settings and stop/start the server. The stats/logs will begin recording again but will stop within a couple hours.  This is getting frustrating.

 

Have the same problem as well....

ok, support blame shoutcast BUT we didnt have this problem before. looks like shoutcast start reading from wrong log example error.log.1 instead of error.log and access.log.1 instead access.log  the number can varies.

here is what you need to do. via ssh access the account folder.

cd /usr/local/centovacast/var/vhosts/USERNAME/var/log

then check the pid number of that account (pid number will be next to  ccuser, THAT LINE WILL END WITH etc/server.conf USERNAME)

ps aux | grep USERNAME

check the process ruining

lsof -p PIDNUMBER

then check if is writing/reading from some file other that a clean error.log and access.log
if that is not the case, KILL it

kill -HUP PIDNUMBER

then verify again

lsof -p PIDNUMBER

If you still see a error.log.1 or access.log.1 (number can varies) try to kill it again and verify.
if does not work and you still see it then go to the account log folder

cd /usr/local/centovacast/var/vhosts/USERNAME/var/log

and delete the logs that ended in a .log.1  , .log.2  etc  just leave clean .log files
from centova cast access the account stop / start and verify again if you still see a .log.1 when you check run:

lsof -p PIDNUMBER

REMEMBER: after you restart the account the PID number will change, you will need to check the new PID number again by using  ps aux | grep USERNAME


IF ALL THIS THAT IS A PAIN DOESN'T WORK, OPEN A SUPPORT TICKET

all this start it after the last update and is a pain to do this per affected account.

I hope this help.


UPDATE:  SHORT VERSION BUT STILL A PAIN.

stop the account from centova cast

GO TO account log folder

cd /usr/local/centovacast/var/vhosts/USERNAME/var/log

delete the logs that ended in a .log.1  , .log.2  etc  just leave clean .log files

from centova cast start the account

then via ssh access check the account folder

cd /usr/local/centovacast/var/vhosts/USERNAME/var/log

then check the pid number of that account (pid number will be next to  ccuser, THAT LINE WILL END WITH etc/server.conf USERNAME)

ps aux | grep USERNAME

check the process ruining

lsof -p PIDNUMBER

then check if is writing/reading from some file other that a clean error.log and access.log
if not and all you see is error.log and access.log then ig fine now.

again I hop this help

same problem. hope fix on next update

there was a newer build posted yesterday so it might be an idea to see if that helps.

though what the 'shoutcast' issue is i don't know unless it's related to the log rotation issue (which is noted as something in the Centova update from yesterday being fixed) as i have no idea if this is due to the known 2.2.x DNAS log issues or quite what (as i see no specific information in people's posts).

The procedure in Javier's post is actually the troubleshooting performed by us which lead to the assumption that this is a Shoutcast v1 bug (so it does not apply to Shoutcast v2 or Icecast) which causes it to (sometimes) fail to reopen its log files when it's sent a SIGHUP signal.


We have been making some changes to the log rotation code recently (although only for the benefit of DNAS2) and have been releasing nightly updates; So if anyone's still experiencing statistics issues we recommend updating to the latest version

rightio, had to ask as it wasn't clear from any of the threads i'd seen what DNAS or specific version was at fault. another reason to drop v1 support imho

I just lost 1 of my 8 clients over this issue today 

The version of the radio station I created for them is ->
Centova Cast v3 Build Your Own Packages - Centova Cast v3 (SHOUTcast v2 Server + Auto DJ, Unlimited Bandwidth, Free cPanel Web Hosting, Instant Setup)

All of my other radio stations work  fine but I am dealing with pressure from some of my other clients that they will also be pulling the plug on their radio station in the next week if this issue isn't corrected properly.

I have a question. Once this bug is corrected will we be able to go back to look at records before it went down? Is there any other solution to get the stats back up and running asap such as changing accounts to something other than the SHOUTcast v2 Server?

Joseph