There is a control protocol event (MOVIE_LOCATION) that provides information about the current location within the movie (i.e. whether playback is in the main content, end credits, or intermission) whenever that changes -- or whenever a control system issues a GET_MOVIE_LOCATION command. This is the event that most control systems use as their cue for lighting events. It can emit the following values:
00 - In the OSD or location unknown
03 - Playing the main content (feature, episode, bonus content)
04 - Intermission
05 - End credits
06 - DVD/Blu-ray Disc menu
The "bug" is that in between script steps, the MOVIE_LOCATION event reports "00" since it's not playing anything, it's not in a DVD menu, it's not in Intermission, and it's not on the OSD so its location is currently "unknown".
Some control systems (e.g. Crestron) can work around this bug by debouncing the MOVIE_LOCATION signal for some amount of seconds to see if it changes again. So during script playback, MOVIE_LOCATION goes to "00" and the Crestron program starts a timer. If MOVIE_LOCATION remains at "00" for, say, 5 seconds, then the appropriate signal is allowed to go high and the lights turn on. But if, instead, MOVIE_LOCATION changes again within that 5 second window, the timer is reset, and the lighting signal remains where it was.
Unfortunately, other control system implementations (e.g. Control4) seem to be much more binary about it and this debounce strategy doesn't seem to work -- at least I've never been able to get it to work but I am a horrible control system programmer.
So the real fix would be to either add a new value to the MOVIE_LOCATION event or to suppress the event in between script steps. We are tracking this issue within Engineering but I don't have a timeline for a fix.