I get this error after upgrading to the latest build:

Starting Centova Cast: cc-control cc-web nginx: [emerg] open() "/usr/local/cento                 vacast/etc/cc-dynamic.conf" failed (2: No such file or directory) in /usr/local/                 centovacast/etc/web.d/cc-content.conf:28
- failed

I dont have a cc-dynamic file. Does anyone?

Force update

I tried that twice now....hmm. Any other thoughts?

Use this comand

/usr/local/centovacast/sbin/update --force

As stated, I have already done that several times. I have one server running the main daemon, then several servers running the web service, ftp server, etc. The main server the web service is working, all of the others are not.

What server should I do the force update on. I have done the force update on 5 servers and the main server twice now in various orders.

I ended up manually creating the dynamic file from the main centova install. Pretty sure there's a bug when you have a non-control panel, streaming only machine install.

I ended up manually creating the dynamic file from the main centova install. Pretty sure there's a bug when you have a non-control panel, streaming only machine install.

This is one time fix. It will stop working after you restart it again (the cc-dynamic file will become empty again).

I figured that, but its better than being down for 72 hours waiting for a response that no-doubtedly will say "We've never seen this before and must escalate this...please wait another 72 hours for a resolution."

It's not to say that some tickets don't get something like a 72 hour wait time (or even more if the solution isn't obvious), but our developers do make themselves highly available in the immediate period after a new release, specifically to address issues like this, or any other bugs, in a timely manner.

Even in your case, you got a reply from a support rep 5 hours after you opened the ticket, and after an additional 3 hours a developer replied and offered to investigate this directly on your server.

Unfortunately, I never knew about the reply because I never got an email reply. I rarely get an email reply regarding my tickets. I've checked my spam filters and don't see any transmissions whatsoever from Centova, not even one to indicate that I created the ticket.

Then you should log onto your Centova account and check the status of the ticket manually.

Pretty sure there's a bug when you have a non-control panel, streaming only machine install.

This was the critical piece of missing information that I needed to track down the problem -- I wasn't aware you were running a control daemon-only installation.  I've resolved the bug and made an update available; see the ticket for more details.  Thanks for the bug report!

I figured that, but its better than being down for 72 hours waiting for a response that no-doubtedly will say "We've never seen this before and must escalate this...please wait another 72 hours for a resolution."

I did respond as soon as I possibly could.  Sorry it wasn't sooner, but I did so as quickly as possible after escalation and a substantial portion of that time was spent trying (unsuccessfully, at the time) to reproduce the issue on our test servers before responding.

Unfortunately, I never knew about the reply because I never got an email reply. I rarely get an email reply regarding my tickets. I've checked my spam filters and don't see any transmissions whatsoever from Centova, not even one to indicate that I created the ticket.

I've sent you the relevant logs from our SMTP servers confirming delivery.  I see that you changed your email address shortly after your post this morning so perhaps you identified a problem on your end? 

I figured that, but its better than being down for 72 hours waiting for a response that no-doubtedly will say "We've never seen this before and must escalate this...please wait another 72 hours for a resolution."

When we contact Centova, they usually reply pretty fast, I'd say within 12 hours, which is acceptable for me...

To fix this issue, they offered me to fix it on our servers, but I feel somewhat hesitant to give root access to our network, as it's against the security policy I've established here