During tests CentovaCast API I found that options "Stop", "Start", "Restart" now working properly.

Everything what i will describe is done by API calls.

"Stop"  stream working fine if you look after on centova cast panel but i think it just stopping sc_serv but not sc_strans.

After when I "start" stream server is starting but "autodj" is not online and after a while I'm getting status that source is connected (I think this is previously not stopped sc_trans).

I have killed all processes sc_serv and sc_trans and started it by starting stream in centova cast panel.

Ano other try with STOP and START server by API call had the same results.

RESTART stream working the same as described above.

During tests CentovaCast API I found that options "Stop", "Start", "Restart" now working properly.

It should be impossible to experience different results via the API than via the web interface.  Centova Cast's web interface performs all operations using the exact same API we expose to end-users.  Granted, in the web interface we bypass the XML interface for performance reasons and directly call the methods using native PHP code, but internally, both the System and Server API classes correspond directly to PHP classes in our code base, so they will always have the exact same effects.

"Stop"  stream working fine if you look after on centova cast panel but i think it just stopping sc_serv but not sc_strans.

If you're basing all of this on what you see in the web interface after running an API start/stop operation, then that's your problem right there.  For performance everything in the web interface is cached, as looking up everything that's displayed in the web interface is a relatively expensive process. 

If you start/stop the stream from the web interface, it "knows" you did it, so it updates its internal cache automatically.  But if you do it via the API (or the commandline) the web interface has no way of knowing you did it, so it will continue reflecting the previous status for up to 60 seconds before checking again.

If you want to force the cache to flush, log out and then log back in.

Hi again.

I found that when I'm calling info method in server class source state is down even is UP.
Web based panel showing that source is up.

My response after calling INFO method:

Code: [Select]

<centovacast host="******" version="3.0.0b2">
  <response type="success">
    <message>Check complete</message>
     <data>
      <row>
       <username>*******</username>
       <state>up</state>
       <expected>up</expected>
       <sourcestate>down</sourcestate>
       <sourceexpected>down</sourceexpected>
      </row>
     </data>
  </response>
</centovacast>


I found also that source PID is not stored in database.

Now I'm sure that when I'm calling 'stop' method again just sc_serv is stopped.
Im getting state that server is offline and there is no source connection but autodj is online (??)
After trying to start server sc_serv starting but no sc_trans, after few seconds i get state that source is connected but  autodj state is offline.

There is still old sc_trans process when I have checked my processes by htop.

'switchsource' method when source is online or offline give me message 'Invalid state for source'.

Restarting is giving identical results

And again just manual sc_trans kill helps :/

'nextsong' method is giving me answer 'Streaming source is not running'. Even autodj is online and is connected to server.

So there is some problem or with API or with source PID which is not stored in database. All positions in database table have '0' in sourcepid column.

I found that when I'm calling info method in server class source state is down even is UP.

Thank you!  Confirmed and fixed for the next build.

Now I'm sure that when I'm calling 'stop' method again just sc_serv is stopped.

Unable to reproduce that at all here.  And again, it's the exact same code as the web interface uses, so if this were the case, everyone should be experiencing this when stopping servers through the web interfaec too.

Im getting state that server is offline and there is no source connection but autodj is online (??)

Commonly that happens if the autoDJ has been started under a different UNIX user account.  Possibly you started it as 'root' during testing or somesuch.

After trying to start server sc_serv starting but no sc_trans, after few seconds i get state that source is connected but  autodj state is offline.

Also consistent with the above.

There is still old sc_trans process when I have checked my processes by htop.

Yet again, consistent with what I described above.

'switchsource' method when source is online or offline give me message 'Invalid state for source'.

That means you're calling it incorrectly -- that message is returned if the "state" option you provided is not one of either "up" or "down".

So there is some problem or with API or with source PID which is not stored in database. All positions in database table have '0' in sourcepid column.

The sourcepid field is a leftover from v2.2 and is no longer used, so it's normal that it would be zero.  I've removed it for the next build.

Unable to reproduce that at all here.  And again, it's the exact same code as the web interface uses, so if this were the case, everyone should be experiencing this when stopping servers through the web interfaec too.

Maybe nobody tested it untill me.

But if You saying there is no possibiliity to be like this then propably thats true.

So what I'm doing wrong ?

I'm using this url: http://mydomain.com:2199/api.php to call api methods.

All centovacast files are under "centovacast" group and root owner.

I'm runnig panel on dedicated server with CentOS 6 and Parallel Plesk panel.

Just start, restart and stop by API calls make problems. Under web interface the same functions are working perfect.

[EDIT] 'Start' working if there is no any server or transcoder process for user account. but after 'stop' is always staying old sc_trans process and after starting comming another one so i have 2 processes with the same config file.
'restart' also giving me 2 sc_trans processes and just one sc_serv. Wierd.......

As I wrote above it looks like that somehow API Stop and Restart functions are working just for sc_serv process but not for sc_trans.

All other methods are ok.

Commonly that happens if the autoDJ has been started under a different UNIX user account.  Possibly you started it as 'root' during testing or somesuch.

No.
Every server and transcoder process is running under ccuser because I'm always starting them under web interface.

'switchsource' method when source is online or offline give me message 'Invalid state for source'.

That means you're calling it incorrectly -- that message is returned if the "state" option you provided is not one of either "up" or "down".

[SOLVED] That's right. My bad.

Every server and transcoder process is running under ccuser because I'm always starting them under web interface.

If that's the case then I can't think of any reason this would happen.  Is this a consistent thing that can be reproduced every time?  And if so, are you running this on a production server, or is it a machine to which you could give me root access to investigate?

This is half-production server. I've got over there website hosting but on the centovacast panel You can work.

I will send You details on PM
[EDIT]

I have done update for centova cast. I have also forced update for sc_trans 2 and sc_serv2 and everything working perfect now....

I forced update because i have read in anothoer topic that newer version of shoutcast was making problems so i think that's true.

So  people don't download manually shoutcast from their wbesite

Centova Cast's installer automatically downloads the latest version of ShoutCast DNAS v2 and sc_trans2 from the shoutcast.com web site when you install/update the packages, so you're always guaranteed to get the latest version when you install/update, just as you would if you manually downloaded it.  We don't distribute any version of DNAS or the encoder with our product as that would violate AOL/Nullsoft's licensing terms.

But glad to hear that updating resolved your issues.

force updated to what versions of the DNAS and Transcoder? as what is on the main site hasn't changed since July and October last year respectively.

and what issues _exactly_ ? as i cannot really tell what is being talked about in this thread as it's somewhat of a jumble of things.

-daz

force updated to what versions of the DNAS and Transcoder? as what is on the main site hasn't changed since July and October last year respectively.

That's sort of what I was getting at -- unless he was using one of the very first CCv3 betas, he pretty much had to have already been using the same version of the DNAS/encoder that he force-upgraded to.

and what issues _exactly_ ? as i cannot really tell what is being talked about in this thread as it's somewhat of a jumble of things.

Pretty sure all of the issues in this thread are CC bugs and/or a problem with Headshaker's installation as opposed to issues with the DNAS/encoder.

It sounds like CC just didn't have control of the encoder process for some reason, which in every case I've seen has been the result of our management daemon running under a different UID than the sc_trans process.  Once that happens, the kernel blocks the daemon from sending signals from sc_trans due to the UID mismatch, so CC can no longer control it.

Hi,

I found issue in API.

When calling system.info API method sourceexpected property is not changing.

I have deactivated source in CC panel, this is result of calling 'info' method:

{"type":"success","response":{"data":[{"username":"demo","state":"up","expected":"up","sourcestate":"down","sourceexpected":"up"}]}}

Result after stopping server in CC panel:

{"type":"success","response":{"data":[{"username":"demo","state":"down","expected":"down","sourcestate":"down","sourceexpected":"up"}]}}

In both cases 'sourceexpected' should be 'down' as well.

Hopefully it will be fixed for the next build which hopefully will be released soon

Regards
(Headshaker)

Got answer for above from Customer Support:

"
This is because if a stream's autoDJ is set to "Permitted and enabled", and Centova Cast detects that an live DJ has used the "Deactivate source" option to temporarily turn off the autoDJ, but no source is connected, Centova Cast to automatically restart the autoDJ. This can be useful in case a live DJ disconnects and forgets to reactivate the autoDJ.

If you would like to disable this, you should simply edit the file /usr/local/centovacast/etc/centovacast.conf and change AUTODJ_FAILSAFE= to "false" (and restart Centova Cast after that:
/etc/init.d/centovacast restart

Regards,

Alexiu
"

Just in case if someone  would like to find out what is going on.

But I found something else, data returned by "version" action of System API  is different fromresult in documentation

{
   "type": "success",
   "response": {
      "data": {
         "web": {
            "version": "3.0.6",
            "accounts": 18,
            "activeaccounts": 17,
            "memfree": 5311606784,
            "memtotal": 8219455488,
            "memcached": 471158784,
            "swapfree": 2006958080,
            "swaptotal": 2006958080,
            "buffers": 49565696,
            "memavail": 7698731008,
            "cpuload": 0.66,
            "uptime": 3000483,
            "machine": "Quad-Core AMD Opteron(tm) Processor 1385 @ 2.70GHz x86-64",
            "osbrief": "Linux",
            "osdetails": "2.6.32-220.13.1.el6.x86_64",
            "other": {
               "Kernel": ["s", "Linux version 2.6.32-220.13.1.el6.x86_64 (mockbuild@c6b6.bsys.dev.centos.org) (gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) ) #1 SMP Tue Apr 17 23:56:34 BST 2012"],
               "Load (1m)": ["f", 0.4200],
               "Load (5m)": ["f", 0.6600],
               "Load (15m)": ["f", 0.5700]
            }
         }
      },
      "message": "Centova Cast v3.0.6"
   }
}