Centova Technologies Forum
Centova Cast v3 => Bugs and issues => Topic started by: computin on January 26, 2012, 04:02:35 am
-
I need generate the YP authentication hash, but not enter to http://www.shoutcast.com/my-stations and options for this site http://wiki.winamp.com/wiki/SHOUTcast_Authhash_Management not shown in the admin section of my Shoutcast station V2, please help :-[
-
Server Status: Server is currently up and public (no YP connection)
-
Hello,
This looks like the function for creating a YP Authentication Hash was incorporated into sc_serv V2 from build 29 onwards, however Centova Cast Beta 3 looks to be using Build 19.
I will add this as an issue on our issue tracker that this needs to be upgraded. I am going to try and manually upgrade the version I have running to see if that works.
-
OK, so to solve this one all you need to do is go to this page:
http://www.shoutcast.com/broadcast-tools
Download either the 64bit or 32bit depending on your system (You should know this), extract the files locally and upload all of the contents replacing all of the files to /usr/local/centovacast/shoutcast2
You will then be given the following screen (After click administrator login at the top right of the DNAS admin)
http://screencast.com/t/mw1eiMwvNfB
-
OK, whilst this does allow for the creation of a hash, it doesn't ever show you what it is, so it very soon reverts back to not having one....
I will wait on the development team for updates on this situation as I suspect they will have to resdesign this part of the system, thanks to shoutcast!
-
Which command I can use to move and replace files from the temporary folder? still can not fix the error
-
Any news on this, I had tried the method by Mark Randall before but not able to get it to work any more, will only play if YP is set to never, when I try to click on update hash I get
Error Code: 470.
"Invalid authorization hash"
-
My problem to pls fix that
http://mptuga.com:2199/start/pdclinks/
http://mptuga.com:8000/index.html?sid=1
-
You just need to remove the YP hash key under encoder settings,
change
YP authentication hash: abcdef
to
YP authentication hash:
-restart your server
- go back to your SHOUTcast DNAS, you will then see the create hash link
The only problem is that it does not seem to like to remember it so when you restart again you may loose it and have to do it again :(
----------------------------------------------------------------------------------------
Server Status: Server is currently up and public (YP connected)
Stream Status: Stream is up at 128 kbps with 0 of 100 listeners (0 unique)
Listener Peak: 0
Stream Name: 2K22DAY.COM Playing the HOTTEST HIP HOP HITS
Content Type: audio/mpeg
Stream Genre: Hip Hop
Stream URL: http://2k22day.com
Current Song: Chris Brown - Poppin
-------------------------------------------------------------------
Much thanks to DRO from the SHOUTcast forums for this info!
-
There reason the updated hash isn't "sticking" is because (for security reasons) Centova Cast configures the ShoutCast DNAS configuration file perms such that ShoutCast DNAS can only read it -- NOT write to it. So after sc_serv generates the auth hash, it can't save it to the configuration file, and thus it remains valid only until the next time you restart sc_serv.
This item is now at the top of our tracker and I'm about to attack it over the next day or two -- I believe the most straightforward approach will be to simply have a "Generate Auth Hash" button in Centova Cast which communicates directly with sc_serv to obtain and save the hash automatically.
In any case, one way or another, the next build will have a solution for this issue.
-
O ok, I see, well as I said I have it working, but only with a couple accounts. Now the problem is (for newer accounts) when I click on Create Hash it just stalls and says
Processing..
This may take a while
I asked a guy from SHOUTcast forums to help and he also had the same problem with a demo account I set up for him, seems to think it could have to do with the sc_serv file.
- also my bandwidth stats and the current listener page does not work, but these are very minor problems, my V3 server is currently running 6 account and the load just stays so low, many times when I look at it it's at like 0.02, had this been the older v2 the load would be triple that at least, as you can imagine this makes me very happy as we can fit more accounts on the server! Now hopefully soon I will be able to beat that one provider's cost whom I will leave nameless, it's the one that has auto dj + server package for $1/m -- you know who you are, after Paypal fee what do you make about $0.75?
Steve is there a way you could notify us of updates, possibly through the forum, updates are so quick and easy it's not like we have to go through a huge process.
Thanks again Steve!
-
O ok, I see, well as I said I have it working, but only with a couple accounts. Now the problem is (for newer accounts) when I click on Create Hash it just stalls and says
Processing..
This may take a while
That looks to be a sc_serv issue... we don't really have anything to do with what happens internally in sc_serv when it generates a new hash.
I asked a guy from SHOUTcast forums to help and he also had the same problem with a demo account I set up for him, seems to think it could have to do with the sc_serv file.
Assuming you mean the sc_serv configuration file, if he can be more specific about what it has to do with the configuration file, I'm happy to modify it with a workaround... I can't reproduce this, though, and we're not doing anything in the configuration file that's explicitly disallowed (afaik) so it's hard to know what it could be.
- also my bandwidth stats and the current listener page does not work
Feel free to start new bug report threads with details for both of these. I'm not aware of any such issues in the latest build.
Steve is there a way you could notify us of updates, possibly through the forum, updates are so quick and easy it's not like we have to go through a huge process.
With the offiical relaunch of beta2 (coming very soon as we're nearly done all of the "major" bugs in the tracker) we will make the update announcements public. Right now, officially, the public isn't even supposed to be "in on" the beta at this point. :)
-
FYI, this build is up on the download servers now.
-
Nice!! Updated in < 2 minutes! The listeners page is very nice! I'm guessing we just need to upload the city database to the geo folder for cities - is that correct? Clients love that listener page, expecially when they actually get listeners :) They also love the stats pages, had a stats page problem recently and clients freaked, they love em!
I guess I am the only one with bandwidth stats problem, could it be a setting on my server?
I found a few more things also, having to do with templates will create a post
-
This item is now at the top of our tracker and I'm about to attack it over the next day or two -- I believe the most straightforward approach will be to simply have a "Generate Auth Hash" button in Centova Cast which communicates directly with sc_serv to obtain and save the hash automatically.
the only viable way would be to pull the stream configuration details from sc_serv once the authhash has been generated and then manually save it to the configuration file along with an appropriate streamid_x=x line so the current build of the DNAS can cope with the new streamauthhash_x=y setting when the configuration is reloaded (otherwise it's possible for the public build of sc_serv to not see the streamauthhash value in some cases).
otherwise there is no way to remotely obtain an authhash unless you have access to partner api to be able to create an authhash outside of sc_serv (since it's far easier in generally to just do it all inside sc_serv without having to mess around with site account creation and logins to get things - you can blame me for that as i implemented it.
You just need to remove the YP hash key under encoder settings,
change
YP authentication hash: abcdef
to
YP authentication hash:
i'm not sure if this is the case with the new version as to why 'abcdef' has been set as the default value for the authhash. but really it should be left as a blank entry if ever unsure.
i have tried to get the OP to update their version of sc_serv to a newer test build (though appears to be issues with it being deployed) to see if that resolves the 'processing...' issue. it would also have the means to ignore the 'abcdef' authhash so one can be created irrespective of the defaults as allowing for the manual entering of the authhash, etc.
though in general i'm probably going to be hated (or maybe not) as a lot of things have changed since the current public build of sc_serv to what i'm working on currently for what will become the next version - which is generally refinements to make some behaviour (like auto-loading of sc_serv.conf) to be move v1 DNAS like and additions to make things like management of the streams _hopefully_ easier.
-daz
-
I've now deployed the newer sc_serv build and looks like i need to do some more work on my side since the inability to write the settings to the config file is preventing the update of the running settings being correctly applied (haven't tried with the public build of sc_serv so anything is possible with that at the moment).
From what it looks like, a temporary file is used for the config file to start sc_serv which is then removed once it has loaded? If so then i can at least improve some aspects of sc_serv's handling so that my suggestion of then being able to pull from the server details i.e. admin.cgi?sid=1&mode=viewxml&page=6 would then be viable.
[edit]
ok changing the authhash works ok with the fixed sc_serv test build (silly optimisation gone wrong) though still need to improve the ui reporting when in this situation.
-daz
-
as an update, the new build appears to be working as expected and the sc_serv instances which were having issues in creating an authhash are now working so far including preserving of the authhash between restarts (i guess i was wrong about the temp file maybe?).
still not sure if that's just something from the test build begin used or if b29 will cope ok as well but my main focus is ensuring the test build is ok (as it appears to be) since that is almost an rc version of the next v2 release.
if there are other issues with the centrova + sc_serv v2 interactions that the dev team have question about, etc then please feel free to contact me.
-daz
-
Welcome, daz!
I was actually mistaken about the nature of the issue with the auth hash -- it turned out that Centova Cast was in fact simply overwriting it, plain and simple. My apologies -- hope that didn't cause you any diagnostic aggro!
As for the permissions, I had forgotten that after I discovered that SC2 likes to write to its own configuration file (which is a bit unusual for a daemon in the UNIX world), I changed our security model to permit this. Prior to that, for security reasons, Centova Cast ran sc_serv under a different UID than that which owned the configuration file. That had the (intended) effect of stopping it from making modifications to files outside of its log directory. Now it runs under the same UID so it can do whatever it likes, for better or for worse. :)
-
My YP hash problems are gone, I have a different version of sc_trans though but the process from creating the hash to editing it is seamless and error free.
-
it turned out that Centova Cast was in fact simply overwriting it, plain and simple. My apologies -- hope that didn't cause you any diagnostic aggro!
no aggro at all, it helped improve the config and authhash update code so that's a good use of time.
I had forgotten that after I discovered that SC2 likes to write to its own configuration file (which is a bit unusual for a daemon in the UNIX world) ... Now it runs under the same UID so it can do whatever it likes, for better or for worse. :)
yeah, i can see it being deemed as a bit strange but is the lesser of two evils as allowing the authhash management to be done in-DNAS makes things a lot easier (especially with builds without some of the issues the public build has) then having to go to shoutcast.com, registering there, creating the authhash and then adding it into the config file.
that was causing too many issues and complaints and so the in-DNAS option came about since it can be done in 3 clicks to go from and back to the server admin page if all of the details from the source are what is wanted :)
well the main thing is that it seems to be working ok in combination with things which is good for all concerned.
[edit]
there we go, finally managed to post the reply. kept getting a "could not open socket" error for the last few hours trying after clicking on the post button.
-daz