Start a new topic

Preset Recall lock up (too many chiefs?)

Can simultaneous IP processes confuse the IP control of the cameras?  I'm running an NDI 12x with a straight-through cat5 cable to a PC.  The PC is running OBS with the camera as a source.  Camera control is primarily done with a Stream Deck configured to send HTTP-CGI commands as well as python scripts sending Visca over IP commands (thanks for the demo code BTW).   


When I've had either have the PTZOptics controller app V1.4, or Internet Explorer logged into the camera at the same time of trying to do the above it experiences what I'll call a 'lockup' mean that it will not respond to recalls of presets, commanded by either the stream deck or the IR remote..  Video is fine, the camera WILL respond to IR commands for pan/tilt/zoom but  ignore  recall of presets.


Sometimes  operation of the Pan/Tilt will get the camera to respond to recalls,  sometimes a 'home' command will free it up; and sometimes It takes restarting the stream deck & OBS (have not needed to restart the camera).


I'm still experimenting to trouble shoot this but it occurs far less frequently, if at all, when just OBS running with Stream Deck sending control commands, without IE or PTZOptics Controller app logged in at the same time


My guess that the camera doesn't like too many devices trying to talk to it, but it is strange that it affects the recall command but not others.


Hi Mark,


This is an odd one, we have never seen issues from being logged into multiple locations for control. If multiple locations execute a command, it should just do the most recent one. I can bounce between (2) presets all day long without any issues happening from the control app or using the remote. I would try and remove things from the setup until it works fine, and use that info to narrow down what device is causing this issue. If you think it is the camera I would make sure it is fully firmware updated, but if that does not work reach out to us at support@ptzoptics.com and we can look into things further. 

Thanks for the reply.  

After further testing  I think I narrowed it down to one of two things.... at least I made changes and the problem seems to have  stopped.

1). When using the stream deck I had a multi action first send preset recall via http-cgi and then after a delay call a python script to send a visca command for iris setting.  Without a sufficient delay (>=2500mS)  between the two commands the problem would sometimes occur.    The other thing I discovered basically at the same time was that Window Defender was finicky about the python executables.  I had to add the  executable scripts to the list of security  exceptions to get them to run consistently.  Not sure that would foul the camera since I'm guessing the script never ran as opposed generating erroneous signals to the camera (so that issue probably has nothing to do with the camera locking up.

Having made these two changes I have had no more occurrences but I'm still gun-shy about calling for these commands during live recording.

Login to post a comment