[2022.28040 Win] WebSocketDat not working

[2022.28040 Win 10] WebSocketDat is D.O.A. Putting the device on active doesn’t appear to do anything. Have tried turning off firewall but that hasn’t worked.

Hey @ENDVR

Close other websocket connections and TouchDesigner projects before testing, ideally:

If you lay down a websocket DAT in a new TouchDesigner file.

You leave the port to 80 and add the following network address: echo.websocket.events/ws

Nothing will print ? You should see a line echo.websocket.events sponsored by Lob.com

Best,
Michel

Hi @JetXS ,

Thanks for your quick response. I’ve layed down a websocket connection in a new TouchDesigner file and entered in the network address you provided. Still nothing is printing.

Can you please share the .toe file with us here ?

Thanks,
Michel

I will once the new user cooldown is over

I gave you the rights to upload the file.

Best,
Michel

Oh great, thanks so much!
WebSocket_Test.toe (4.0 KB)

So the file you just shared, doesn’t show anything in the DAT for you ?

Could there be something blocking the port on your machine ?

Are you using some kind of streaming software like OBS or Stream.Bot… etc ?

No nothing like that prints in the DAT. There must be I guess. I have OBS installed but it hasn’t been running when using TD. I will investigate further if there is a socket being blocked or something similiar.

It appears that port 80 is open. Are there any tests I can do to see if something is stopping TD from communicating via tcp?

Edit: I can confirm this .toe file does not work on my mac either, nothing prints. I have Anaconda installed on both, perhaps that is the problem? Is there a command I can run in the textport to see what’s going on?

Can you try to see if things run locally:

Open 2 TouchDesigner processes, in 2022.28040.

In process A:

  • open the palette
  • go to the WebRTC folder
  • drag n drop the signalingServer COMP
  • Toggle its Active parameter

In process B:

  • open the palette
  • go to the WebRTC folder
  • drag n drop the signalingClient COMP
  • Toggle its Active parameter

Go back to process A:

  • What do you see in the viewer of the signalingServer COMP?
  • Can you take a screenshot and share it here?

Thanks,
Michel

Sure thing, both sets of parameters were kept at their default values.

An ID, address and some text in the properties column shows up in the signalling viewer.

We output internal connection errors from the WebSocket DAT to the TouchDesigner text console, which can be opened by setting the environment variable TOUCH_TEXT_CONSOLE=1, then reopening TouchDesigner.

Could you retest with one of the examples where it was failing while the TouchDesigner text console is open, and send us any errors?

Thank you for the reply.

I’m sorry i’m a real noob, how do I set the environment variable?

Edit: Nevermind I worked it out. It looks like the connection is timing out almost instantly.

Thanks.

Potentially related issue: https://forum-new.derivative.ca/t/websocket-no-connection-with-twitch-irc/280324

I’ve looked into it but haven’t found the cause yet, and I have yet to reproduce.

From running the signalingClientCOMP example, it looks like it works between processes on the same machine for you. Does it work between machines on the same local network?

Do non-local WebSocket connections work for you outside of TD?

My current TD version is 64-Bit Build 2022.29850 on Mac
Hey there, I am having the same problem here. I made a ping-pong test in the websocket. I test it out with websocketking, I can both receive and send message through the websocket. But I cant seems to make it work in Touchdesigner. Dou you guys have any idea? Cheers

I’m on 2022.31030 and having issues setting up a non-local WebSocket. Can connect with other web socket clients (Chrome/Postman) but can’t connect in TouchDesigner websocketDAT or socketioDAT:

Postman echo test also seems to fail in Touch, but not in other clients:

Perhaps something is wrong with my syntax?

Ok, yes. I can confirm that this is broken in the 31030 release (right side). Works as expected in 2021.15800 (left side).

I took another look into it today and found a bug that could be the cause. I implemented a fix here:

Could you test with this build and let me know whether or not it fixes the issue for you? I’ve been unable to reproduce the issue on my end so I’m not able to verify the fix.

2 Likes

Hey @eric.b, thanks so much for looking into this so quickly!

I just tested 31170 and it seems to still be failing: