[BUG] Companion on Intel Sequoia 15.1

[Lukeb873]

Is this a bug in companion itself or a module?

• I believe this to be a bug in companion

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I'm setting up a machine that will only run companion. We heavily use companion and are needing to have everything point to this one installation with satellite. I'm using a older 2018 Intel mac mini for the "server." It's a intel i7 with 16gb of DDR4 ram. More than enough for companion. The mac is on mac OS Sequoia 15.1. Currently the mac mini has wifi turned off and has a static IP assigned to the ethernet port. Currently every module is spitting out errors. If I export the config and load it onto my M2 Air, everything works fine. In my head this rules out Sequoia being the issue and it being an intel mac is now the issue. I then tried the same config on an Intel iMac running Sonoma 14.7. It also worked fine on that. So now I'm not sure if it's a companion thing, an intel thing, or a software version thing. I also tried another mac mini running Sequoia 15.1 with the same config on a wired connection with wifi off and a static IP and ran into the same issue. This mac mini was a intel i5 16gb DDR4 from 2018.

Everything was running a freshly downloaded version of 3.4.3 from the website

Steps To Reproduce

No response

Expected Behavior

No response

Environment (please complete the following information)

- OS: Sequoia 15.1
- Browser: FireFox
- Companion Version: V3.4.3

Additional context

No response

[Julusian]

Those errors are all suggesting that companion isn't able to reach various hosts on your network.
Make sure that they are reachable and that the macos firewall isn't blocking the connections.

We are not doing any differently in how these connect for intel macos, we build each module once and use that same build on every os

[Lukeb873]

I am able to successfully ping every connection from the mac os terminal. The firewall is also turned off on this mac... I've never ran into this before and it's happenning to two freshly factory rest mac minis running Sequoia 15.1. Like I said, it's not happening to my M2 air or the intel iMac on Sonoma. With being able to ping devices from it, the firewall being off, and all the other testing I did, this is what lead me to post here.

[Lukeb873]

So by turning off the local network connection and re enabling it, companion seems to be happy. I'm going to role the computer back to 14.7 and see what happens. We'll likely disable all updates on this computer to not go to 15 until something is figured out on Apples end.

[JRNYproduction]

We're having the same problem with a brand new M4 MacMini. ANY wired network connection (built in or dongle) leads to the same failed communication with network based modules... so all of them. We're also having intermittent issues with ATEM connection and UltraStudio SDI outs from the same machine. One time it'll work, and then we restart and then it doesn't work. I think this has something more to do with Sequoia. I'd love to know what people find for workarounds other than "roll back to 14.x" as this machine cannot do that.

[niklasarnitz]

So by turning off the local network connection and re enabling it, companion seems to be happy. I'm going to role the computer back to 14.7 and see what happens. We'll likely disable all updates on this computer to not go to 15 until something is figured out on Apples end.

We’re also facing the same issue.

M4 Mac Mini, static IP address.

After switching the network connection of and on again, it works.

[niklasarnitz]

As a temporary fix, we just wrote a script to restart the network interface:

#!/bin/bash

# Give the system a moment before toggling the interface
sleep 1

# Disable Ethernet
/usr/sbin/networksetup -setnetworkserviceenabled "Ethernet" off

# Wait one second
sleep 1

# Re-enable Ethernet
/usr/sbin/networksetup -setnetworkserviceenabled "Ethernet" on 

[JRNYproduction]

I've also tracked down another solution that might point to the cause... in Privacy & Security > Local Network it seems like turning Companion off and back on fixes the issue. So it's likely something in the OS not playing right with Companion. I also had to click "allow" network connections after installing the new Companion version like 12 times. That was strange.

[Julusian]

I also had to click "allow" network connections after installing the new Companion version like 12 times. That was strange.

I think I can answer this part, since 3.0, companion runs each connection as its own process. So I suspect that '12 times' was once for each connection you have (plus one or two for companion itself)

I suppose macos getting upset could be related to this, with it getting confused/upset with the processes whenever one starts or stops?
I probably need to try running companion for a while on my mac, to see if I can trigger this behaviour..

[Lukeb873]

Some of you did what I suggested by turning the Local Network Permission on and off for Companion. I thought that this was a Intel issue first with Sequoia because this intel mac worked when it was on Sonoma. It's weird that on my M2 Air on Sequoia 15.2 does NOT have issue. It seems to be an issue with Intel and M4 Mac. I don't think there's anything Bitfocus can do and this is a wait it out until Mac fixes it in an OS update.

[JRNYproduction]

Yeah. Bummer. After Christmas I'll move all of Companion to our main computer and run the others as clients and see if that "fixes it" permanently.

[Lukeb873]

So, I just pushed Sonoma 15.2 to the intel mac and everything was working correctly after multiple restarts. Then it randomly broke again with the same errors that I posted originally. Interestingly, I noticed that if I adjust any of the local network permissions for literally any of the apps (even if is not companion) it fixes companion. I'm wondering when apple plans to fix this as we're planning to replace all of macs with M4 minis this year. If the network stack is so busted that it's causing this many problems, it'll be a pretty rough transition.

[lfrisk]

Sequoia added stricter measures to local network privacy. Here is their developer guide for understanding network privacy. There is a video linked from this document that spells out that if an app running on macOS does not have a complete and accurate info.plist, then the app will be blocked from communicating on the local network.

Until either developers or Apple conform to each other, keep your macOS on Sonoma where restrictions are not as tight for local network permissions. I am still unclear why this only effects certain mac hardware platforms though.

I am just a Companion user that tried updating my Intel iMac to Sequoia ran into issues that could not be remedied and had to resort to reformatting and loading Sonoma again. Every app on the Sequoia installation (ATEM, Videohub, Companion Satelliite, ProPresenter, etc.) had Local Network permissions approved, however these were unilaterally blocked after restarting the system. Then, by toggling of one local network permissions selectors, this unilaterally un-blocked each device that was blocked.

[Lukeb873]

Yep, this sounds exactly like what we're experiencing. I do agree that it's weird it's only on specific hardware platforms. They do the same thing every OS update where they create a stricter network stack. This one just seems to be almost too strict and I hope it gets resolved soon.

[alexmarshall37]

Has anyone found a consistent fix for this issue yet? I have a client who just updated a machine that was running Sonoma to Sequoia and now companion doesn't connect to the ATEM. Short of asking them to roll back to Sonoma, is there a specific security setting that I can have their IT department change in the Firewall? The company's security measures are pretty robust so that coupled with Sequoia's issues, is making this really hard.