|
|
 
|
|
Author
|
Topic: Doremi Ethernet command reliability
|
Steve Guttag
We forgot the crackers Gromit!!!
Posts: 12814
From: Annapolis, MD
Registered: Dec 1999
|
posted 01-17-2018 07:29 AM
I'm curious, from those of you that use the Doremi (including its newer Dolby incarnations) how many have had reliability issues on the various servers issuing Ethernet commands (TCP/IP).
I've noted on our installations that the overwhelming amount of time, they work but enough times they don't work to make it VERY frustrating. If I double-fire commands (just issue the same command in the same macro 1 second later) then the reliability skyrockets. I've had problems with both the traditional (DCP) and the the IMS varients. Thus far, it is not software/firmware/sm dependent either. It isn't network switch dependent (have different makes and models, same results). It doesn't matter what device I'm trying to control (had identical type issues with communicating to automations and sound processors). It is most frustrating.
I haven't put Wireshark on it yet but that is coming because I don't know if the commands are simply not sent or if they are malformed and are being ignored the by receiving party.
But since Doremi is the biggest installed base of servers, I have to figure SOMEBODY has come across this. One of the manufacturers of the devices I'm controlling did indicate that this is a known issue with the Doremi Ethernet commands and to merely double them up. If so, how can this sort of defect go on for as long as it, apparently, has.
What say you, the people of Film-Tech?
| IP: Logged
|
|
Ioannis Syrogiannis
Expert Film Handler
Posts: 147
From: Reykjavík, Iceland
Registered: Jun 2005
|
posted 01-17-2018 09:40 AM
For one, I would say that there are some parameters that have to be taken into account:
Are the macros to be executed simultaneously, or in a sequence of timely divided steps?
Where the commands are sent to? (And that has to do a lot with the next question…)
What else is going on within the subnet in question?
On IMS1000, which ethernet port is used for control?
Once, there was a DCP2000 connected with a CP2000-ZX and connecting the system with a TMS setted with an non-agreeable polling frequency, the projector macros (douser, channels, lamp etc.) had a lag of several minutes, causing pandemonium. Yet, that was more of a projector thing and less of a doremi one.
Firing multiple macros at once, can be an issue for both the projector and the server. It is found to sporadically create issues on doremi and servers of other brands.
Apart from that, the content and control networks on a doremi-dolby server are not clearly distinguished, like, say, the theatre and auditorium networks of a DSS, that might turn to not being convenient, also.
In some cases, the line change or termination character of a macro can differ between servers. (Even thought you obviously don’t ask for such incidents in your post.)
Personally, I believe that the (ethernet) network side of things is not as predictable nor as robust as we would all wanted it in a cinema environment, and that goes for other equipment too.
Just like a chromecast device could cause wi-fi connectivity issues with your home router, another networked apparatus, that we love for its remote accessability that saves us of quite a few miles of traveling every now and then, might as well create frustration in a theatre near you…
I would like to hear more of what you described, Steve, (or others are about to) related to the overall network picture of the places. Are the macros a bit choosy on where and when they misbehave the most, or are they time, usage and cinema-blind?
| IP: Logged
|
|
|
|
|
|
|
|
Marcel Birgelen
Film God
Posts: 3357
From: Maastricht, Limburg, Netherlands
Registered: Feb 2012
|
posted 01-17-2018 03:36 PM
I can confirm the issues Dave and Ioannis have pointed out, regarding firing multiple commands to the same device in sequence. I'm not sure if this is always due to a problem in the server not sending the commands or the receiving end simply not being ready for a new command.
So, when we need fire two or more sequential commands to the same receiving end, we're usually putting in a short pause. Multiple of those pauses can sometimes result in somewhat awkward long silences in the show, so if possible, we try to "distribute" the commands over the playlist when possible, in order to avoid those pauses.
I've not seen a general failure for "singular" commands, like Steve seems to experience. Although, I have seen IP commands from a Doremi to the CP650 go wrong quite a few times. Then again, the remote control IP implementation of the CP650 is a single threaded, wonky one, best consumed in RS232/serial-only mode.
| IP: Logged
|
|
|
|
Stephen Furley
Film God
Posts: 3059
From: Coulsdon, Croydon, England
Registered: May 2002
|
posted 01-18-2018 07:22 AM
Doremi server controlling NEC NC-800c projector and Dolby DMA8Plus.
Used to sometimes have problems if commands to the projector were very close to the start of the item to which they are attached, usually a black. Now always put the first cue at least two seconds into the black, and never put in two commands at the same time stamp. Very seldom have problems now, just occasionally when testing a show playlist something doesn't work, and delaying it slightly more fixes it.
Don't see any problems controlling the DMA8Plus; it just works, unless I've made an error in the playlist.
A problem which I do still see is that if a playlist is run from the beginning and just left to run through until it ends, or is stopped then it works, but if I step back in the list to check something then all commands in the list after doing that are ignored. No idea why. Stepping forwards sometimes works, but not always.
| IP: Logged
|
|
Steve Guttag
We forgot the crackers Gromit!!!
Posts: 12814
From: Annapolis, MD
Registered: Dec 1999
|
posted 01-18-2018 06:02 PM
quote: Ioannis Syrogiannis
I would like to hear more of what you described, Steve, (or others are about to) related to the overall network picture of the places. Are the macros a bit choosy on where and when they misbehave the most, or are they time, usage and cinema-blind?
No, not really. Early on, I noted that the Doremi line had an issue communicating to our automation of choice, eCNA series so I doubled up the cues to work around the problem. The eCNA logs cues so I could see if they were taking or being missed. Doubling up the cues effectively put a band-aide on the problem.
More recently, the customer has decided they needed to put MANY more volume cues into the SPL to combat various Ads and Trailers to have them play back at what they deem a comfortable level. This really showed off the problem since I still had those cues set up as single commands to the respective sound processor (DCP100s, in this case).
quote: Harold Hallikainen
Doremi added a \w escape sequence to add a short delay (I don't really know how long it is, but it does not seem noticeable). Putting \w before the command and after the terminating character (\r for the JSD) improves reliability substantially.
This sounds like good advice, thanks Harold! I was talking to someone that indicated that they thought that the receiving device was closing its socket too fast and was missing the cue. However, if I fire cues via the eCNA to the DCP line, they NEVER miss. The eCNA allows one to configure to leave a port open or open it with each communication. Either way, it never misses. Oddly enough that is not the case on the JSD-100 where one almost has to fire off a socket open cue at the beginning of the day since the first cue will be lost opening the socket. This is notably true of you have a GDC server talking to a JSD100...GDC will open a socket and leave it open but it doesn't open it until that first cue is fired.
quote: Ken Lackner
If a sound processor is set up for ethernet control rather than contact closure, it will get the commands from the automation. I am not aware of any cases where the projector or automation has missed commands from the Doremi server. If this has happened, it is an occasional glitch that has not been reported to me.
Normally, that is the case for us too. On this site, I ported over a command list that I used on a Crestron system whereby one can effectively issue cues for volumes form -90dB to +10dB and making that many automation cues would have been "wasteful" on the use of the RDIs of the eCNA automation (I normally only devote one RDI for volume cues and that limits one to 16 discrete volume cues. I augment that a little with leftover cues from the main RDI that talks to the sound processor. Normally, I provide a range from "3.5 - 8.0", using normal 0-10 scale with roughly a 0.25 increment. This has sufficed for most situations. I might switch them over to this but the Doremi isn't the most reliable to cuing the eCNA via Ethernet either (had to double them up to get 100% success.
quote: Dave Macaulay
A long time ago (in D-Cinema time at least) we had problems with Doremi cues if they were stacked (at the same time). So we put longish black sections in playlists so the cues would be spaced a second apart. Some software update made this less of a problem and we do stack cues now, but still need to be careful not to have the same device have stacked cues.
Dave, the cues are not stacked (the ones that are misfiring). They are standalones in a black segment (Doremi "pattern", not a normal Black CPL so there maybe something there to investigate). Most all of my cues are single cues that tell the automation to execute a macro so there is no chance of conflict/flooding.
The customer understands that volume cues must come AFTER format changes (going to DCP 7.1, for instance, since the DCP100s are set to remember the last volume for that format...which has probably hidden the problem since if the feature volume cue is missed, so long as it worked last show, it is good).
quote:
...rom a Doremi to the CP650 go wrong quite a few times
The CP650 Ethernet port is "weak." That is, it can only talk to one thing at at time and it is EASILY "flooded." If you hit it with rapid fire commands, it will shut down on you! The only way to get it back up is to reboot the processor too!
I've been known to use a product like Lantronics on the RS232 port to get a second CP650 "Ethernet" port too.
quote: Marco Giustini
You are talking about ethernet commands going out of the Doremi to another device, right? I have never experienced this issue and never had anybody reporting it back.
That is correct. I've had manufacturers of devices being controlled by Doremi report of problems with it, so I'm not unique. Please note, the projector communication is going to be different than any other Ethernet device. The server and projector have a special relationship since they have to maintain a TLS session, the servers generally are polling the projectors continuously about their status (lamp, douser...etc.) and unlike what else you may throw at the server to talk to, every 3rd party server company HAS to be able to talk to Barco, Christie and NEC and can test there products against them. They are NOT going test against every sound processor, dimmer, automation...etc.
Stephen, see, you're having to do work arounds (where you put the cue and how you space them) to overcome the server's shortcomings. Yes, you do what you have to do to make things work (I'm doing that right now, myself) but that still is a shortcoming of the server.
| IP: Logged
|
|
|
|
|
|
All times are Central (GMT -6:00)
|
|
Powered by Infopop Corporation
UBB.classicTM
6.3.1.2
The Film-Tech Forums are designed for various members related to the cinema industry to express their opinions, viewpoints and testimonials on various products, services and events based upon speculation, personal knowledge and factual information through use, therefore all views represented here allow no liability upon the publishers of this web site and the owners of said views assume no liability for any ill will resulting from these postings. The posts made here are for educational as well as entertainment purposes and as such anyone viewing this portion of the website must accept these views as statements of the author of that opinion
and agrees to release the authors from any and all liability.
|
Home
Printer-friendly view of this topic