Dolby cp950 Cues Issue

[Avinash Kamath]

Hi,
I face one issue in Dolby cp950 , After I update new ver.2.0.0 the Automation cues are not working. Please any one help me for that.

Thank you
Avinash
Digital Tech. KNCC kuwait.

[Elia Orselli]

With the software update Dolby changed the string terminator (that wasn't required before): now you have to add a \n at the end of each command.

Important Note: When upgrading from v1.0.4.2 or earlier versions to v2.0.0.0, you may encounter an issue with the CP950 automation control. In earlier versions of CP950 software, automation commands could fail when more than one command arrived at the same time. To resolve this issue, we added the requirement for a termination character at the end of CP950 automation commands. This character is \n. We made this change to ensure compatibility with devices that send multiple automation commands for a connection and to match the implementation on other Dolby devices. For example, sys.fader 70 would change to sys.fader 70 \n.

[Avinash Kamath]

Thank you very much dear Elia Orselli.

[Leo Enticknap]

That gotcha also bit me recently when updating a CP850 from an ancient version to 2.3.2.2: automation cues fired by a Crestron system all stopped working. However, my vague memory is that adding a carriage return (\r) rather than a linefeed (\n) was what fixed it, but I'm likely misremembering. Still, this appears to be an occupational hazard when updating either model of processor installed in a system that controls it by IP-based automation.

[Bruce Cloutier]

It is unfortunate that programmers lack the attention to detail or, maybe, the depth to see what issues they might cause down the road when making a seemingly minor correction. This probably comes from a lack of real world experience with the code they are responsible for. I usually accept either a carriage return (\r, 0x0D) or a newline (\n, 0x0A) as a terminator whichever you encounter first ignoring the second if it is present. Some issues come with DOS vs. Linux where you might get CRLF, just LF or even something else when you hit ENTER.

On the JNIOR when you enter login credentials for the command line interface we also accept TAB (\t, 0x09) as a termination just because, well, you get into the habit of username<TAB>password<ENTER> when dialogs popup. You then do that at the prompts without thinking and would be refused.

If they liked the \r as the correct termination they could have still kept the \n just to not break everything.

[Elia Orselli]

This update add the termination character, before there was no termination required for any CP automation command

[Marcel Birgelen]

That gotcha also bit me recently when updating a CP850 from an ancient version to 2.3.2.2: automation cues fired by a Crestron system all stopped working. However, my vague memory is that adding a carriage return (\r) rather than a linefeed (\n) was what fixed it, but I'm likely misremembering. Still, this appears to be an occupational hazard when updating either model of processor installed in a system that controls it by IP-based automation.

It depends on what your receiving end is expecting. Some devices work with either \n and/or \r and others require both \n and \r.

The update stripped the automatically inserted termination. This can be important when interfacing with some esotheric hardware that uses other means of command termination.

[Bruce Cloutier]

Dolby programmers also had/have the TCP/IP misconception that with each READ you get one PACKET which contains one MESSAGE. That falls apart because TCP/IP is a stream of characters and should be thought of as the same as a (error-free) serial cable connection. So with each read you might get 1 or more characters representing possibly a partial message or even a whole message plus some of the next. In their initial testing they send one message at a time and on a quiet network and everything works. But reality is another creature.

So without a protocol they need the terminator so they can tell where one message ends and the next starts. Oops. Ergo, the sudden appearance of the terminator. Because if the media system sends more than one message back-to-back the Dolby would fail. Or, more likely, if the Dolby collects a message but takes its sweet time getting around to read it and the media system decides that perhaps to be safe it repeats the command and something fails. Recall, some of you bang messages twice to somehow feel more confident that what you need will in fact happen.

Over the years we have caught many people on this, not just Dolby and not just in this market. It is a rookie mistake and what you would expect if they don't employ extremely experienced programmers. We have all made this error early in our careers. I mean, if you had ever programmed some communications from the network. It is quick and easy just to read and process as a message and that works the majority of the time in controlled situations. Great for prototyping. Going back later to employ a buffer/queue and to detect (and validate) complete messages before processing is a more complex step that, well, maybe you can get to later and... later never comes. Well, until another release of the product and you get to confuse a whole bunch of users.

Just saying.

[Steve Guttag]

I find the need to repeat commands due to how some devices send them (or abruptly closing the socket) a bit too common and disturbing. Some devices need to double send in the hopes that the message actually gets there. Some need to double send in the hopes that it is heard. Honestly, I've found the Doremi and by extension, the Dolby IMS to be miserable at how they send. One is advised to always bookend a command with \W (or at least a \w)...which is almost an admission of guilt that they had to add those wait commands. I have devices that have been controlled by a multitude of other devices without issue...not so with the Doremi/IMS where you might need to double-up the command. It is just wrong. Often, just bookending the command with the \W is sufficient. The Doremi/IMS stuff seems to close the socket with a "RST" packet. I believe that a FIN packet and there should be a FIN/ACK dialog to shut the socket down.

I've found the NEC projectors to a bit hard of hearing as well...it all depends on what they are doing at the time...with the older projectors having a harder time.

[Bruce Cloutier]

Also the \w wait will tend to allow the underlying TCP/IP stack to flush its buffers thus causing the message to be transmitted (hopefully) as one packet. The read() at the receiving end then would get the packet and (what it assumes is) a complete message. I bet Dolby in this case just changed from a read() to a readline() or whatever reads a terminated line in whatever language they are programming in with whatever libraries. This avoids the risk of scarfing characters from the following command or not getting an entire message but now requires the terminator.

If the sending system doesn't actually issue a close() on the socket and the socket object gets destroyed then perhaps the RST as opposed to the proper TCP/IP closing sequence. Again, a rookie mistake and the result of not actually looking at what you are doing on the wire as validation. I prefer to first call flush() and then close() although that is not strictly necessary. If for any reason the receiving device cannot accept the packet (yet) then flush() might block fending off the actual close(). Some of these devices just don't have the background processing to collect network traffic fast enough.

No two TCP/IP stacks are created equal. You might think that by now these are specified in great detail what with all of the RFCs and sample code out there. The reality is that there is a lot left to the programmer requiring reading between the lines. I hated that in English class where we had to read a book (enough of a pain) and then in class all of the questions had nothing to do with the plot and everything to do with what wasn't strictly written (and therefore between the lines).

It is amazing how the slightest little programming variance can eventually snowball into a support nightmare. And, then, correcting the error not result in making life any easier.

[Tony Bandiera Jr]

.......It is amazing how the slightest little programming variance can eventually snowball into a support nightmare.....

Truer words have never been spoken...

I used to write custom AMX AXcess code programs for clients. One client requested the ability to adjust brightness and contrast on a Christie CP 2210. I was able to get the correct serial commands from Christie and wrote the appropriate code, which the AMX code compiler happily passed.

I uploaded the program to the system in question and......nothing. No response from the projector. A quick review showed that I was sending the strings in the wrong format (ASCII instead of integer). I corrected that, compiled, and reuploaded. The projector responded....by slamming the brightness and contrast to full black! OOPS.

Several tries at fixing the code did not get any better, so I disabled that section of code until I could get it resolved. A few weeks later, after getting a more experienced programmer on the phone with me while on site, he discovered that I had omitted ONE special character (I think it was the " character) in my code. Adding that in made it work perfectly.

Worst part of all this was when I wrote the first iteration with integers I had that extra character in place, but deleted it thinking it was redundant.

[Avinash Kamath]

HI
I try to update CP 950 New firmware from ver1.0.0.697 to ver. 2.0.0 but its not loading processor will disconnect after half an hour . Then i restart the CP950 afterword's the network IP is not saving it will go directly default . Can you plz advise me how to reset network default and why my IP is not saving ?

[Elia Orselli]

Hello. To upgrade to 2.0.0.0 you need to be at least at 1.0.4.2, as indicated in release notes

[Avinash Kamath]

Hi Now their is any chance to fix this issues ,any solution