search

SteffeyDev / atemOSC

Control ATEM video switchers over the network with OSC messages
http://www.atemosc.com
202 stars 32 forks source link

Port issue on atemOSC #259

Closed c434techteam closed 1 year ago

c434techteam commented 2 years ago

I have had several occasions now where atemOSC stops responding to commands being sent to it from OSCulator. I noticed this first when I thought it was the version of the ATEM Software Control I was using, but it turned out that wasn't the case. When I first setup atemOSC, it was listening on the default port, 3333, and then stopped responding. On a whim, I changed the port to 5555 and it started working again. Yesterday, that port stopped working as well, but later came back when I disconnected atemOSC from the switcher and reconnected.

The scenario I'm using is I have this on a Mac Mini M1 with 16GB RAM, running ProPrenter 7, LightKey, ATEM Software Control, OSCulator and atemOSC. I'm successfully able to use ProPresenter to control Lightkey, using Midi, every time. I have periods where I can control the ATEM from ProPresenter 7 through OSCulator, but the breakdown comes with atemOSC and the port. OSCulator shows atemOSC using UDP and I read somewhere that UDP isn't as reliable as TCP, but I'm not sure if we can switch the configuration to use TCP.

The main thing is I would like the port being used to always be available, without having to disconnect and reconnect from the switcher. I'm not sure what is causing it to happen, but if anyone has any ideas to make it more reliable, I would greatly appreciate it.

SteffeyDev commented 2 years ago

Thanks for explaining the issue. It's tricky to debug these issues, so I'll probably leave this thread up to see if other users are experiencing this as well. I can say that the OSC protocol is built on UDP, so TCP isn't an option. However, even though UDP is less reliable, it won't just quit working for a time period. Less reliable for UDP means that it might drop some packets, but if you re-send a few times at least one of them will get through.

Does disconnect and reconnect always fix, even if the port stays the same? Does changing port always fix without disconnecting or reconnecting? Or is it more random than that?

c434techteam commented 2 years ago

Thanks for explaining the issue. It's tricky to debug these issues, so I'll probably leave this thread up to see if other users are experiencing this as well. I can say that the OSC protocol is built on UDP, so TCP isn't an option. However, even though UDP is less reliable, it won't just quit working for a time period. Less reliable for UDP means that it might drop some packets, but if you re-send a few times at least one of them will get through.

Does disconnect and reconnect always fix, even if the port stays the same? Does changing port always fix without disconnecting or reconnecting? Or is it more random than that?

Changing the port seems to always fix it (at least the two times I've tried it). I've only tried the disconnecting and reconnecting once and the port was left the same, if I remember correctly. I believe I changed it to 7777 first, then back to 5555 before disconnecting and reconnecting.

I'll keep playing with it to see if I can find anything else of use. I'm a Mac newbie, but are there any logs or anything I could look at that would help me diagnose it?

SteffeyDev commented 2 years ago

atemOSC has logs in the bottom panel, feel free to attach those if they are relevant

ezbutton commented 2 years ago

Concerning port 3333, if you have software that uses OLA (Open Lighting Architecture), it may take UDP port 3333. I am running LightKey and it launches olad on 3333. So, I switched to using a different port and it works fine. You can run the below to see which UDP ports are in use:

lsof -Pn | grep UDP

c434techteam commented 2 years ago

I've had it happen on 5555 as well, but thanks for the command to check the ports. I was able to use it all Sunday using port 7777 and in this case I didn't have the ATEM Software Control launched. Not sure if that had anything to do with it or not, but I was under the impression that I needed to have it opened, but it appears you don't.

SteffeyDev commented 1 year ago

Yes, you don't need ATEM software control open, atemOSC and ATEM Software Control use the same underlying SDKs to communicate with the switcher and are not connected

c434techteam commented 1 year ago

I haven't had the issue in a while. I've left it configured on port 7777. I will close the this out.