Error when attempting to connect.

[varrus2]

I have tried a few of the examples on both a windows and mac machine and as soon as the script tries to connect I get an exception in Thread-4. I'm sure it is just me doing something dumb, any help would be appreciated. Thanks.

[Thu May 6 15:44:57 2021] Connecting to 192.168.199.240 Exception in thread Thread-4: Traceback (most recent call last): File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.1520.0_x64__qbz5n2kfra8p0\lib\threading.py", line 954, in _bootstrap_inner self.run() File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.1520.0_x64__qbz5n2kfra8p0\lib\threading.py", line 892, in run self._target(*self._args, **self._kwargs) File "C:\Users\Mark\Proshow Audiovisual\Engineering - Projects\Show Control\ATEM Controlers\PyATEMMax-master\examples\PyATEMMax\ATEMConnectionManager.py", line 306, in _commsThreadHandler while self._runLoop(): File "C:\Users\Mark\Proshow Audiovisual\Engineering - Projects\Show Control\ATEM Controlers\PyATEMMax-master\examples\PyATEMMax\ATEMConnectionManager.py", line 481, in _runLoop self._parsePacket(packetSize) # Parse EVERYTHING, don't trust packetLength !! File "C:\Users\Mark\Proshow Audiovisual\Engineering - Projects\Show Control\ATEM Controlers\PyATEMMax-master\examples\PyATEMMax\ATEMConnectionManager.py", line 714, in _parsePacket self._parseGetCommands(cmdStr) File "C:\Users\Mark\Proshow Audiovisual\Engineering - Projects\Show Control\ATEM Controlers\PyATEMMax-master\examples\PyATEMMax\ATEMConnectionManager.py", line 731, in _parseGetCommands self._cmdHandlers[cmdStr]["callback"](cmdStr) # Call method File "C:\Users\Mark\Proshow Audiovisual\Engineering - Projects\Show Control\ATEM Controlers\PyATEMMax-master\examples\PyATEMMax\ATEMCommandHandlers.py", line 92, in _mainHandler self._getHandler(cmdStr)() # Call specific handler File "C:\Users\Mark\Proshow Audiovisual\Engineering - Projects\Show Control\ATEM Controlers\PyATEMMax-master\examples\PyATEMMax\ATEMCommandHandlers.py", line 742, in _handleSSrc self._d.superSource.border.inner.width = self._inBuf.getFloat(16, False, 16, 100) File "C:\Users\Mark\Proshow Audiovisual\Engineering - Projects\Show Control\ATEM Controlers\PyATEMMax-master\examples\PyATEMMax\ATEMBuffer.py", line 198, in getFloat return self.getInt(offset, signed, bits) / factor File "C:\Users\Mark\Proshow Audiovisual\Engineering - Projects\Show Control\ATEM Controlers\PyATEMMax-master\examples\PyATEMMax\ATEMBuffer.py", line 149, in getInt return struct.unpack(self._getFormatChar(signed, bits), packedValue)[0] struct.error: unpack requires a buffer of 2 bytes [Thu May 6 15:44:58 2021] ERROR: no response from 192.168.199.240

[varrus2]

Never mind. It seems related to connecting over my VPN. Thanks.

[clvLabs]

Thanks for the report anyway !
I might try to reproduce this error and change the code to have something friendlier than an exception :)

[slampants]

I'm actually running into almost exactly this same error. I'm on a Mac, and I'm not on a VPN:

>>> switcher.connect("192.168.86.7")
>>> Exception in thread Thread-4:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/threading.py", line 954, in _bootstrap_inner
    self.run()
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/threading.py", line 892, in run
    self._target(*self._args, **self._kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/PyATEMMax/ATEMConnectionManager.py", line 306, in _commsThreadHandler
    while self._runLoop():
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/PyATEMMax/ATEMConnectionManager.py", line 481, in _runLoop
    self._parsePacket(packetSize) # Parse EVERYTHING, don't trust packetLength !!
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/PyATEMMax/ATEMConnectionManager.py", line 714, in _parsePacket
    self._parseGetCommands(cmdStr)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/PyATEMMax/ATEMConnectionManager.py", line 731, in _parseGetCommands
    self._cmdHandlers[cmdStr]["callback"](cmdStr)  # Call method
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/PyATEMMax/ATEMCommandHandlers.py", line 92, in _mainHandler
    self._getHandler(cmdStr)()  # Call specific handler
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/PyATEMMax/ATEMCommandHandlers.py", line 742, in _handleSSrc
    self._d.superSource.border.inner.width = self._inBuf.getFloat(16, False, 16, 100)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/PyATEMMax/ATEMBuffer.py", line 198, in getFloat
    return self.getInt(offset, signed, bits) / factor
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/PyATEMMax/ATEMBuffer.py", line 149, in getInt
    return struct.unpack(self._getFormatChar(signed, bits), packedValue)[0]
struct.error: unpack requires a buffer of 2 bytes

[slampants]

I'm going to see if I can figure out the source of the bug, but as a follow-up (in case any of these give you a clue to an easy solve), I've switched logging to DEBUG mode, and here was the full output:

ATEM_debug.txt

[clvLabs]

Sorry for the late answer!

I'm seeing a log of unknown command receptions... Do you know which firmware version you have on your switcher ? If it's above 7.5.0 you might be experiencing compatibility problems.

Anyway, please try to add the following line to your initialization code:

switcher.setSocketLogLevel(logging.DEBUG)

Then, repeat the test and save the complete output (it will be long) to a text file and attach it to this thread. With the socket output in the log I can try to simulate as I'm receiving it.

[slampants]

No apology necessary! I dug in a little and determined that what's happening (though this is probably not the actual thing that needs to be fixed) is that it's receiving a "packedValue" of b''. I added a try/except clause to getInt that just returns 0 if this is the issue, and that allowed me to connect!

But you're right, my firmware version is indeed above 7.5.0. I didn't notice there was a note about compatibility issues.

Output you requested is attached

ATEM_OUTPUT.txt

[slampants]

I've done a little testing and once I get the ATEM connected using the hack adjustment I made, I've been able to successfully change the program source!

If you would accept my solution (or something similar), I'd really love the opportunity to make a pull request and formally contribute to the code base!

[clvLabs]

Of course, that would be very nice of you!

The only thing here is ... this will be my first pull request :)
Go ahead and do the request, I'll have a look on how to accept it and then I'll make a new version of the library.

Thanks!

[slampants]

Opened pull request #8

GitHub makes it pretty easy to merge changes. As it happens I've really only added like two lines of code, so if you want you could copy-paste it into your own code, do some testing with hardware you have, ensure functionality, and choose whether to merge the pull request or not. Let me know if you need help and I'll do my best to be of assistance!

[clvLabs]

Just reviewed it and clicked the merge button 😄

No real need of hardware testing on my side, I trust you did your testing and the code changes suppose no risk at all, they in fact lower the risk.

Thanks for the tabbing/spacing fixes as well.

I'll do a version bump and upload the package to PyPy as soon as I can (won't be long).

I'll keep the issue opened until this happens.

[slampants]

Awesome! Thank you for helping me unlock the achievement of my first accepted contribution to an open source repo 😄

[clvLabs]

First time for me on this side as well 😄

[clvLabs]

PyATEMMax v1.0b5 is already available at PyPi