Lamp Not Turning On, Dowser Not Opening?

[Ryan Gallagher]

Nice input, Caleb.
I wonder if it would cover more cases when you were to add that "force" operator:
shutdown /r /f /t 0
(I was under the impression that it was "-" instead of "/", but I haven't used that command since... Windows XP?)

Ryan, if there isn't any linux machine at the booth, an old generation* Raspberry π might have been a nice idea.
Those "Windows Linux Subsystem" implementations on recent Windows OSes are nice. You can ssh in a server without having to use PuTTY, for instance. But I don't think they fit well the idea of cron scheduled tasks.
(*No substantial benefit from a younger generation, unless you are looking for high speed Ethernet.)

a 24/7 raspi that has such utility in my booth is definitely on my todo list. Might have to hide it from our IT person though. lol. (mostly joking, kinda).

For the script at discussion... does it somehow ignore show-times? Or have you found it a non-issue to reboot the TPC during a screening. I know if I do it manually it complains about not being able to do lamp power adjustments until next projector reboot (not that we have any targets turned on). I would worry about it deciding it needed a reboot towards the end of pre-roll, right before the SPL has a bunch of commands it needs to respond to.

[Ioannis Syrogiannis]

On a cinema I was working, they were using those to screen ads/slides via the HDMI/DVI ports.
On a festival, they were using those for signage outside the auditoria, mostly for showing ticket availability, open doors etc, etc.
On another cinema, I used one as a VPN server, to get remote access. (100Mbps, but that was not a problem for the use case.)
Those machines are quite versatile, as they were made to be.
One may find valid reasons to have one (or more) in a projection booth. Yet, for a number of uses, it wouldn't make sense to go behind the IT's back.
(Maybe have one to do one trick and secretly use it for more. )

I don't know about how Caleb uses his script, but cron scheduling can be quite configurable on the time periods when it runs a script.

[Ryan Gallagher]

I don't know about how Caleb uses his script, but cron scheduling can be quite configurable on the time periods when it runs a script.

For sure, cron is very flexible, and can be made to ignore certain hours etc. But as the object of the script is to catch TPC communication problems as they occur and prevent automation disruption, I would imagine it needs to run during the times the projectors are in use as well, cause this issue certainly can not exist for one screening, and be present for the next disrupting the show.

[Caleb Williams]

I wonder if it would cover more cases when you were to add that "force" operator:
shutdown /r /f /t 0
(I was under the impression that it was "-" instead of "/", but I haven't used that command since... Windows XP?)

Ryan, if there isn't any linux machine at the booth, an old generation* Raspberry π might have been a nice idea.
Those "Windows Linux Subsystem" implementations on recent Windows OSes are nice. You can ssh in a server without having to use PuTTY, for instance. But I don't think they fit well the idea of cron scheduled tasks.

I'm a linux guy, and I've found that generally its best to run commands with the least amount of parameters as possible (though that may not be true on Windows). Running "shutdown /?" on the TPC command line showed that all of those options were valid. I did not test with /f but it should work just fine with or without. Windows cmd is weird to me with the "/".

Others are suggesing that running this script may interfere with showtimes. Our shows generally start every 15 minutes, so I just scheduled the cron job to start at least 7 minutes after the hour, to avoid the 15 minute blocks. The TPC generally only needs 3-5 minutes to boot, so this avoids messing with pre-roll stuff. I haven't seen that it's effected anything towards the end of a show yet, but I've probably gotten lucky. We generally don't have channel changes after a show starts. If the TPC is rebooted during a show, from what I've seen, it has no effect on the playback of a show. Control of the projector is lost of course, but it will continue happily playing in whatever channel it was in with the lamp on while the TPC reboots. When the TPC is fully booted, the projector state is re-synced and things are as they were before, except hopefully the stuff on port 5000 is working now. If you had nodejs or asp.net installed you could whip up a relatively simple query to the IMS to see if it's playing and avoid rebooting the TPC during that time. We haven't needed to do that with this set-up yet.

The specific crontab entry we use is below:

# Christie tpc watchdogs
# morning
07 17-23/1 * * * /tmsserver/service/christie_watchdog/tpc_check_trigger.sh 2>&1 /dev/null
# afternoon/eve
07 0-7/1 * * * /tmsserver/service/christie_watchdog/tpc_check_trigger.sh 2>&1 /dev/null

I use the tpc_check_trigger.sh which is a simple wrapper for a loop that goes through the IP Scheme. The server this is running on is UTC, hence the two entries to cover different parts of the day. This also avoids mostly the times we expect the projector to be off (overnight).

The contents of tpc_check_trigger.sh are

#!/bin/bash
for s in {192..201}; do
/tmsserver/service/christie_watchdog/tpc_health_check.sh [IP_SCHEME].$s >> /tmsserver/log/tpc_watchdog.log
done
exit 0

In this case, theater 1 (191) is a series 3, which don't have this problem. Logging is enabled by the ">> /tmsserver/log/tpc_watchdog.log" part of the command. You can change the path to the log to wherever you'd like. If you plan on running this for any period of time I would recommend setting up auto-log-rotation wherever the log is stored. If things are set up and forgotten, you could eventually run out of disk space on whatever you're running otherwise.

A note on WSL:
Any Windows 10 and newer can run WSL version 2, although it is not set up to automatically run when the computer reboots. WSLv2 now also supports Systemd, which is a service manager for linux. There are a few guides on how to set up WSL to start automatically using Task Scheduler, then you could potentially use Systemd or cron to run anything you'd like. I have not tested this, although WSLv2 is super solid and well supported by Microsoft.

I don't have a lot of time to develope, and am a bit of a novice. Our goal with this setup is to avoid scenarios where a customer finds out about an issue before we do by hopefully just resolving and logging it. Ideally a perfect system would be able to catch the issue, notify the relevant parties, then if certain conditions are met, fix itself. Bash is not really good for communicating via api to the IMS and other systems, but it's just fine for basic socket communication. If I had time to do it over I would pick a different framework and build out a system that could do all of that. All of that is to say, your mileage may vary, and I'm completely open to suggestions.

[Ioannis Syrogiannis]

Yes. Ideally, we would address the cause, instead of the symptom (the unresponsive TPC).

[Caleb Williams]

Yes. Ideally, we would address the cause, instead of the symptom (the unresponsive TPC).

Would love to do this. However, Christie haulted development on their series 2 line of projectors a while ago. We will not get a software update to fix this