Lamp Not Turning On, Dowser Not Opening?

[Nathan Paris]

Hey everyone! We use Christie CP2220s, Dolby DSS200s, and Cat862s.

I have 7 screens at my theater, I have had an issue the past few weeks with two of my projectors not having the lamp turn on or the dowser open when it runs a playlist. It ignores the cue so we have to manually turn the lamp on and open the dowser and then when the show ends it also ignores the cue and we have to go and turn the lamp off and shut the dowser. The house lights still went down as normal according to their cue.

I've had this happen once in a while across my time working but it has been happening repeatedly the past few days for about a week. Restarting everything after the first show fixes it for the next (and remaining) show of the day but then the next day when we power on all our equipment again it has a chance of happening again.

One other issue related that we had is that one of those screens was constantly repeating the first few seconds of the playlists when we looked at it on our Arts Alliance Media Screenwriter and when trying to override it on the DSS200 the show control was locked.

Any help would be great! I've been trying to look for any existing topic but all I seem to find is bulb related issues, nothing on the lamp/dowser just not turning on or off despite having cues to do so.

[Leo Enticknap]

To distill this a bit, is the situation that all cues sent from the server to the projector are failing to work? If so that, combined with the repeating the first few seconds behavior, suggests to me that the fault could be in the DSS200.

If it were me, the first troubleshooting step would be to try to send API commands to the projector from another device (even manually via an SSH or Telnet connection if necessary: don't know what Christie uses). If they work OK, that would narrow it down to the DSS200. Next, can you ping the projector from the DSS200 successfully? If no, there is a communications problem (maybe another device has the projector's port locked open?). If yes, something is not right with what the DSS200 is sending to the projector. In that scenario, my suggestion would be to "nuke" the DSS200, do a clean install of the software, reconfigure it, reingest everything from the TMS, and see if the problem goes away.

and when trying to override it on the DSS200 the show control was locked.

You can unlock it in the system > theatre tab, as so:

image.png

[Ryan Gallagher]

Not an expert, but this feels automation/network related. Are the lamp and shutter commands via TCP/IP or some other method?

One thing that happens with our CP2220 and TCP/IP commands (and I haven't learned exact cause) is that the TPC embedded windows will get very laggy over time or randomly. When it's in that laggy state VNC connections are difficult to use, as well as incoming TCP/IP automation commands will execute extremely late, perhaps in worst case get missed?

Our "band-aid" unfortunately is to force the TPC to reboot, and while you can do with the lamp on and content running, you lose some lamp power management features until the next full projector standby cycle. We have avoided doing it during shows. But I will reboot the pedestal or TPU only if I start the day with that interface feeling sluggish, and have mostly avoided cue lag issues since adopting that practice.

I suspect our network infrastructure doesn't have the Booth equipment as isolated as it should be, and the system can get kinda clobbered dealing with broadcast type network traffic and ARP requests, ending up in some kind of less than responsive state. I need to poke our IT dept to look into it.

[Nathan Paris]

To distill this a bit, is the situation that all cues sent from the server to the projector are failing to work? If so that, combined with the repeating the first few seconds behavior, suggests to me that the fault could be in the DSS200.

If it were me, the first troubleshooting step would be to try to send API commands to the projector from another device (even manually via an SSH or Telnet connection if necessary: don't know what Christie uses). If they work OK, that would narrow it down to the DSS200. Next, can you ping the projector from the DSS200 successfully? If no, there is a communications problem (maybe another device has the projector's port locked open?). If yes, something is not right with what the DSS200 is sending to the projector. In that scenario, my suggestion would be to "nuke" the DSS200, do a clean install of the software, reconfigure it, reingest everything from the TMS, and see if the problem goes away.



You can unlock it in the system > theatre tab, as so:

image.png

So I believe some cues are still coming through as our house lights will still go down as normal when it hits that cue in the playlist, it's just specifically been the dowser and lamp that isn't turning on/opening. I'll try pinging the projector. I've had to run a clean install of the DSS200 setup before so if it keeps happening then I'll do that!

[Nathan Paris]

Not an expert, but this feels automation/network related. Are the lamp and shutter commands via TCP/IP or some other method?

One thing that happens with our CP2220 and TCP/IP commands (and I haven't learned exact cause) is that the TPC embedded windows will get very laggy over time or randomly. When it's in that laggy state VNC connections are difficult to use, as well as incoming TCP/IP automation commands will execute extremely late, perhaps in worst case get missed?

Our "band-aid" unfortunately is to force the TPC to reboot, and while you can do with the lamp on and content running, you lose some lamp power management features until the next full projector standby cycle. We have avoided doing it during shows. But I will reboot the pedestal or TPU only if I start the day with that interface feeling sluggish, and have mostly avoided cue lag issues since adopting that practice.

I suspect our network infrastructure doesn't have the Booth equipment as isolated as it should be, and the system can get kinda clobbered dealing with broadcast type network traffic and ARP requests, ending up in some kind of less than responsive state. I need to poke our IT dept to look into it.

Our TPC has been very laggy in any of the instances I've dealt with it, so I think you're spot on with that. We shut off all of our equipment nightly so that would functionally cause the TPC to reboot, wouldn't it? Or is there a more official way to specifically force a reboot of the TPC? I believe our cues run through IP? It's all serial automation through the DSS200.

[Ioannis Syrogiannis]

[...]
So I believe some cues are still coming through as our house lights will still go down as normal when it hits that cue in the playlist, it's just specifically been the dowser and lamp that isn't turning on/opening. I'll try pinging the projector. I've had to run a clean install of the DSS200 setup before so if it keeps happening then I'll do that!

Yet, the light cues are not cues that are sent to the projector, right? We don't even know if the light cues are running through the auditorium/control network or serial connection.
If it was the lens' cues that were still working, then it would have been meaningful.

I support Leo's suggestions. The problem seems to be on the network connection between the screen server and the projector (Ryan also mentioned it). I would (besides that) underline the fact that you use a third party TMS (not the Dolby one, that would have needed license, I suppose, for seven screens(?) and is abandoned by Dolby for the sake of the Doremi one, that was... also abandoned).
So, before a fresh install, I would first check if the problem resolves itself by
1) checking -and maybe reducing- the polling frequency between the TMS and the projectors
2) while keeping the projector fully on (the lamp makes no difference) and connected to the server, running anew the configuration setup (the server is retrieving the automation cues/channels during that procedure)

Best of luck!

[Ryan Gallagher]

Our TPC has been very laggy in any of the instances I've dealt with it, so I think you're spot on with that. We shut off all of our equipment nightly so that would functionally cause the TPC to reboot, wouldn't it? Or is there a more official way to specifically force a reboot of the TPC? I believe our cues run through IP? It's all serial automation through the DSS200.

I agree it depends a bit on which cues are working and which are failing. Could be a mix of serial/TCP/gpio and different destinations. If ALL projector cues are suffering but nothing else is, that kinda focuses your attention.

When you say power down nightly, do you mean “stand-by” mode, or completely removing power? Stand-by notably DOES NOT cause the TPC to reboot.

I bet there is a more kosher way to do a clean shutdown of just the TPC, but simply unplugging it and replugging it will force it to reboot. At the risk of damaging it’s little connector if done all the time.

Again, this, if it helps at all, is just a band-aid and not really solving the underlying problem.

Before I started rebooting ours everyone avoided projector automations like a plague cause they were so unreliable in their timing. I would prefer some automation in some situations so had to wrestle with it to find a way forward.

[Ryan Gallagher]

Sharing which firmwares and software versions the CP2220 is on might also be useful info. I know ours is probably behind a couple versions... but it's not the kind of thing my org likes to touch unless something is not working. (Obviously something isn't working quite right, but it hasn't risen to the level of making my superiors want try updating to fix it yet).

It's a hard thing to recreate under test conditions... but if you can get a moment when it is misbehaving, I agree with Leo that having a second device you can try sending projector commands from would be good. If it is non-responsive or super delayed on those too then that narrows it down to the christie automation handling or the network situation. I should do so myself!