Centova Technologies Forum
Centova Cast v3 => Bugs and issues => Topic started by: miedzius on October 29, 2014, 06:03:14 am
-
Welcome, today I was update my SHOUTcast DNAS to lastest version. But after start server I got a problem:
Diagnostic output from streaming software:
===============================================================================
[01;33m2014-10-29 13:58:05 WARN [CONFIG] Could not find `../demo/etc/server.conf' - looking for config file to load...
-
the 2.4.1 DNAS had to slightly change how it handles file paths (done in the build 165 update) to ensure that all of the native functionality will work correctly as expected (which was not happening in build 164).
as such, you may need to adjust the relative path used to provide server.conf to the DNAS when it starts (i assume there's a means to configure that) or it might be easier to instead have it use an absolute file path instead (which is always the safer option so you know it's going to use the correct config file in all cases).
-
Hello,
how can we solve this error?
on my server the same thing happened after updating to shoutcast.
-
Afternoon, DrO! Centova Cast does not make this configurable so I'm curious about how this is handled in DNAS 2.4.1, as we'll need to make some changes to accommodate this.
We currently do a chdir() to the directory dedicated to the stream, then invoke sc_serv passing the relative path to server.conf, eg: "/path/to/sc_serv etc/server.conf". I tried a few variations here and it appears that relative paths are no longer accepted at all... could you elaborate on what you meant by "adjusting" them?
It isn't a huge deal as we can certainly use absolute paths, it's just that on servers that host more than a couple dozen streams, using the absolute path (which is long due to our directory structure, eg: /usr/local/centovacast/var/vhosts/username/etc/server.conf) really clutters up the process list and makes it harder to pick one process out of the list.
-
the chdir() you're doing is going to be ignored as we're resetting it when the DNAS starts to be the same as the current location of sc_serv (which was previously only done with daemon mode but is now done for all modes), which i expect is probably a no-no to do but it ensures all of our local file lookups work correctly across all of the platform versions (as not doing it was causing things during setup and the cacert.pem lookups to fail).
if not wanting to do absolute paths, basing the paths relative to the sc_serv location should do it. as i did test things (though clearly not for the same way that its called by Centova) when doing the build last night and it was working with what i tested (unless i've broken the build even more...).
-
i guess we'll need to roll another build and re-work the changes.
[edit]
we're going to re-work things from our side (ignore the prior post) so will look to have a new build available tomorrow. sorry for any inconvenience this update has caused people.
-
Hello,
ok let's get to wait for tomorrow.
Thanks.
-
We are happy to hear that! So now we are waiting for new build.
-
Hope that it will be fixed soon. We've faced the same issue here as well.
-
Will we have to uninstall and reinstall everything...?
-
no.
i'm currently waiting on feedback to see if a test build i've sent out to a few people does correctly resolve the issue that has been seen (include a copy being sent to Steve). when i've got some feedback (hopefully confirming things are ok) then we'll be releasing a 2.4.2 update.
-
Any update?
-
we are waiting news :-\
-
The new build (2.4.2 build 167) is now available (as of ~30 mins ago) and the update flag has been enabled so the DNAS will report a new version is now available.
Centova have confirmed the pre-release build works ok so is down to how you need to update the DNAS now to get the fixed version being used.
I will also add that such issues with the DNAS (which are clearly an issue with the DNAS) should be reported to SHOUTcast directly. As it's only by chance that i saw this thread so soon after the prior release, otherwise it could have been a few days or longer.
-
[root@centova ~]# /usr/local/centovacast/sbin/update --add shoutcast2 --force
Checking Centova Cast Common Files ...
Downloading Centova Cast Common Files ...
Verifying archive integrity ...
Unpacking archive ...
Installing Centova Cast Common Files ...
Installation successful
Checking shoutcast2 ...
Downloading shoutcast2 ...
Verifying archive integrity ...
Unpacking archive ...
Installing shoutcast2 ...
Unable to determine latest release, aborting
Installer exited with error, aborting
[root@centova ~]#
-
I am having the same problem.. :(
-
Try again as we've changed the download links for our needs and i suspect the Centova update isn't liking it. I've added back equivalent links of the prior format so that should hopefully allow the update check to work again for the moment.
-
No luck. Still the same problem,,,
-
[root@centova ~]# /usr/local/centovacast/sbin/update --add shoutcast2 --force
Checking Centova Cast Common Files ...
Downloading Centova Cast Common Files ...
Verifying archive integrity ...
Unpacking archive ...
Installing Centova Cast Common Files ...
Installation successful
Checking shoutcast2 ...
Downloading shoutcast2 ...
Verifying archive integrity ...
Unpacking archive ...
Installing shoutcast2 ...
Unable to determine latest release, aborting
Installer exited with error, aborting
[root@centova ~]#
-
Try one more time (unless something is incorrectly caching the download page results) it might now work.
If that doesn't work, then you can try to manually download and update the DNAS and install it that way.
As the download links we're intentionally changed so it's the same link irrespective of the version (which saves us hassle with updating the website, etc) but might break anything 3rd party (but the style of the links was never guaranteed to be the same).
I have however temporarily put back the old-style links (and altered the order so they come before the new style link), but if it's still not working after doing that then it's pretty much going to need to have Centova update things from their side for their updater - though that doesn't stop you manually updating the DNAS.
[edit]
something is wrong with the uploads... working on it...
-
:-\
[root@centova ~]# /usr/local/centovacast/sbin/update --add shoutcast2 --force
Checking Centova Cast Common Files ...
Downloading Centova Cast Common Files ...
Verifying archive integrity ...
Unpacking archive ...
Installing Centova Cast Common Files ...
Installation successful
Checking shoutcast2 ...
Downloading shoutcast2 ...
Verifying archive integrity ...
Unpacking archive ...
Installing shoutcast2 ...
Unable to determine latest release, aborting
Installer exited with error, aborting
[root@centova ~]#
-
I've re-uploaded the Linux versions as it had the wrong OS version of the DNAS included in them.
If that still doesn't work then other than the manual install option, there is little i can do myself and it'll either have to wait for the morning until i can get our Ops team to check things or for Steve, etc to chip in on things.
-
:-\
keeps equal without updating
[root@centova ~]# /usr/local/centovacast/sbin/update --add shoutcast2 --force
Checking Centova Cast Common Files ...
Downloading Centova Cast Common Files ...
Verifying archive integrity ...
Unpacking archive ...
Installing Centova Cast Common Files ...
Installation successful
Checking shoutcast2 ...
Downloading shoutcast2 ...
Verifying archive integrity ...
Unpacking archive ...
Installing shoutcast2 ...
Unable to determine latest release, aborting
Installer exited with error, aborting
[root@centova ~]#
-
I don't know what Centova is doing / checking. Maybe it's cached the bad copy of the linux install archive.
But as it's now gone 1am in the morning where i am, there is little else i myself can do or check or get someone to check.
At this point i'm hoping Steve will chip in here as there is nothing else i can suggest or do other than to try doing the manual update option or just waiting until someone can find the cause of Centova's update handling failing.
-
Ok, let's wait for tomorrow and hope that helps Steve
Here is also 1am in the morning, time to go to rest.
Have a good night.
See you tomorrow.
-
I don't know what Centova is doing / checking. Maybe it's cached the bad copy of the linux install archive.
But as it's now gone 1am in the morning where i am, there is little else i myself can do or check or get someone to check.
At this point i'm hoping Steve will chip in here as there is nothing else i can suggest or do other than to try doing the manual update option or just waiting until someone can find the cause of Centova's update handling failing.
Unfortunately, Steve is not available at the moment, but for those who can't wait, here is how you install Shoutcast manually.
/etc/init.d/centovacast stop
mv /usr/local/centovacast/shoutcast2 /usr/local/centovacast/shoutcast2_old
mkdir -p /usr/local/centovacast/shoutcast2
wget --no-check-certificate http://download.nullsoft.com/shoutcast/tools/sc_serv2_linux_x64_10_30_2014.tar.gz
tar xzvf sc_serv2_linux_x64_10_30_2014.tar.gz -C /usr/local/centovacast/shoutcast2
/usr/local/centovacast/sbin/fixperms
/etc/init.d/centovacast start
This should work on most systems, and if you need the 32 bit version, just use the link below instead.
http://download.nullsoft.com/shoutcast/tools/sc_serv2_linux_10_30_2014.tar.gz
As always, if you need hands on assistance, feel free to contact me at the installations department.
HTH
-
:)
SHOUTcast Server v2.4.2.167 update was successful.
Centovacast update to version 3.1.1 was successful.
Everything working perfectly.
Thank you to all the team who worked on this update.
-
Well. I uninstalled the old setup and did a fresh reinstall of Centovacast and everything is working....
-
we try do to that but now all customers are offline after that we get this message
Stream could not be started: Could not start server: Application /usr/local/centovacast/shoutcast2/sc_serv does not exist.
pleaseeeeeeeeeeeeeeee help
-
gerys,
can upgrade the centovacast and then the shoutcast 2
/usr/local/centovacast/sbin/update --force
you install Shoutcast manually.
/etc/init.d/centovacast stop
mv /usr/local/centovacast/shoutcast2 /usr/local/centovacast/shoutcast2_old
mkdir -p /usr/local/centovacast/shoutcast2
wget --no-check-certificate http://download.nullsoft.com/shoutcast/tools/sc_serv2_linux_x64_10_30_2014.tar.gz
tar xzvf sc_serv2_linux_x64_10_30_2014.tar.gz -C /usr/local/centovacast/shoutcast2
/usr/local/centovacast/sbin/fixperms
/etc/init.d/centovacast start
-
gerys,
can upgrade the centovacast and then the shoutcast 2
/usr/local/centovacast/sbin/update --force
This is incorrect, the correct command is:
/usr/local/centovacast/sbin/update --add shoutcast2 --force
HTH
-
I did this now all streams are offline
pleaseeeeeeeeeeeeeeeeeee help me!!!!!!
[root@centova ~]# /usr/local/centovacast/sbin/update --add shoutcast2 --force
Checking Centova Cast Common Files ...
Downloading Centova Cast Common Files ...
Verifying archive integrity ...
Unpacking archive ...
Installing Centova Cast Common Files ...
Installation successful
Checking shoutcast2 ...
Downloading shoutcast2 ...
Verifying archive integrity ...
Unpacking archive ...
Installing shoutcast2 ...
Unable to determine latest release, aborting
Installer exited with error, aborting
[root@centova ~]#
-
I did this now all streams are offline
pleaseeeeeeeeeeeeeeeeeee help me!!!!!!
This is probably because you updated Shoutcast while still running an older version of Centova Cast.
Running the update utility script should take care of the problem.
/usr/local/centovacast/sbin/update
HTH