[BUG] Companion on Intel Sequoia 15.x

[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.

[Lukeb873]

What specs is your clients mac? Is it intel or an apple silicon?

The only fix right now is to turn on and off the local network permission for companion every time the computer reboots.

[lfrisk]

Apple is forcing any app or service that uses local device connection to convert their app from basic IP connection framework to multicast connection structure. If an app on your system is not multicast compliant when macOS launches, it appears that it cuts ALL local network access, even for multicast devices. Much like a circuit breaker tripping, once it is reset if the violating device is working smoothly than all the other devices will get "power". This is why disabling and enabling works most of the time. I am guessing that some devices have restructured their apps to be multicast compatible...however I doubt that older versions of anything from BMD is.

If all devices that are listed on your Local Network panel have associated apps that are multicast compliant...then this protection will not trip upon boot. Just a theory.

[Julusian]

Apple is forcing any app or service that uses local device connection to convert their app from basic IP connection framework to multicast connection structure.

Do you have a link to some documentation on this?
We are doing some mdns stuff for discovery of various things (including discovering atems), perhaps that is what is upsetting macos?

[lfrisk]

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.

This appears to be within macOS itself, and not something that is externally controlled by a network admin. The only way to truly "fix" this is for:

1. Every 3rd party developer redo their app to be custom broadcast compliant (and for every user to update all of their apps to the latest compliant version) or
2. macOS lowers the severity of their protection...which noting the small scale of people effected...this is very unlikely to be even considered.

[lfrisk]

Apple is forcing any app or service that uses local device connection to convert their app from basic IP connection framework to multicast connection structure.

Do you have a link to some documentation on this? We are doing some mdns stuff for discovery of various things (including discovering atems), perhaps that is what is upsetting macos?

Here is a developer video from Apple that basically tells how they are restructuring privacy with Sequoia. You can skip forward to 18:15 to see what changes are made for Local Network.

Here is another video geared toward app developers on how to Support local network privacy in your app This video says that if your app uses Bonjour, AirPrint, AirPlay or Homekit... you don't need to make any changes (3:30).

6:20 mentions that an entitlement needs to me requested in the developer portal to allow an app to use multicast or unicast.

[Julusian]

Thanks for the links.

From those and https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy, it looks like we don't need to do anything specific for multicast on macos.
I can add the nslocalnetworkusagedescription in case that helps, but what it says about bonjour worries me. The docs claim that we need to list the bonjour services we try to discover in the app manifest, but it appears to be working just fine without doing that..

If I explicitly toggle off local network permissions for companion (for some reason it shows up called 'electron' for me..), then I get what appears to be the same behaviour here, nothing connects.
Google seems to suggest that we can't explicitly check if we have permission for network access, or to ask for it. So unless I stumble upon something, there might be limited options on what we can do..

[Lukeb873]

What would this mean for companion going forward? Obviously at some point our computers will update or we're buying new computers where there is no way to put Sonoma on them as they shipped with Sequoia.

Also... With Buttons being paid... I imagine it's having the same issue right now...? What would this mean for paid subscribers to buttons and not being able to use it? Obviously it's still in the beta phase, but if it wasn't?

[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.

I was able to get the client's IT department to give me a different computer still running Sonoma, but that seems to be the only real fix at the moment. Hopefully Companion will come out with a fix, but right now I've advised the rest of my team not to update their OS and wait and see.

[Julusian]

Well, hopefully it is a macos bug that will get fixed at some point I suppose, or that someone who knows macos better than I do will come up with a fix.

There is the workaround of

The only fix right now is to turn on and off the local network permission for companion every time the computer reboots.

so it should be usable right now, although a bit tedious.

I've just tried it in a fresh vm (the closest I can get to a fresh mac), and didn't have any issues when rebooting.

Has anyone tried figuring out the minimum setup to reproduce this?
Such as does it happen when using a fresh installation and just an atem connection added. Or it starts after adding connection X. Having some info on this would be helpful, as it could be triggered by a particular module, or could be unrelated entirely.
If it happens without any modules, does disabling the Watch for Discoverable Remote Surfaces setting (3.4 and onwards) have any impact.

[lfrisk]

This is an idea for a workaround, however I haven't tested this...and I don't know how well this will work. Supposedly an AppleScript could be created to launch on startup that would toggle the checkbox of one of the items in your Local Network settings pane. I don't typically like to recommend band-aids, but this could be helpful in the interim if it works.

[Lukeb873]

Well, hopefully it is a macos bug that will get fixed at some point I suppose, or that someone who knows macos better than I do will come up with a fix.

I would honestly be shocked if MacOS fixed this. We're a small enough community that I don't think anyone has the reach to tell Apple this affects how we use their products.

so it should be usable right now, although a bit tedious.

We wanted to transition to having to mac minis run this as a server for our building and everything else remote connecting via satellite. We haven't been able to do this yet because of this bug. Even if we did implement this, we'd have to remote into headless macs to cycle the local network config when they restart weekly which is a massive pain in the butt. There's also a concern of how long that fixes the problem. I originally came up with that solution, but I don't know if it stays fixed. I'm not sure if apple rescans and realizes wait this app shouldn't do this and kills it again.

I've just tried it in a fresh vm (the closest I can get to a fresh mac), and didn't have any issues when rebooting.

I still think this has something to do with the chip sets. It's not an Issue on my M2 air running Sequoia 15.2. However

We’re also facing the same issue.

M4 Mac Mini, static IP address.

This person had said they had it on a M4 mac mini which has to be on Sequoia. Likely 15.1, although they didn't say. It does seem to be a consistent issue on intel macs though.

Has anyone tried figuring out the minimum setup to reproduce this? Such as does it happen when using a fresh installation and just an atem connection added. Or it starts after adding connection X. Having some info on this would be helpful, as it could be triggered by a particular module, or could be unrelated entirely. If it happens without any modules, does disabling the Watch for Discoverable Remote Surfaces setting (3.4 and onwards) have any impact.

So, here are the steps I've taken.

1 - I disabled the Atem BMD module and left everything else on. Restarted the mac mini. No fix
2 - I disabled ALL modules and restarted the mac mini. Then turned on the Atem BMD and it could never connect.
3 - I disabled ALL modules and disabled the watch for new remote surfaces then restarted. Then turned on one of the modules. It wold never connect.

If there's anything else you can think of to try, let me know. Also, first time I tried to quote something, so we'll see if I did it right

[meonlylouder]

@Lukeb873 Interesting development for me troubleshooting on my client's two M4 Pro Mac minis: Companion and Elgato Stream Deck were not even appearing in the list of apps to be allowed access in System Settings > Privacy & Security > Local Network! I did just upgrade to macOS 15.2 this morning, so maybe they needed to re-gain permission after the initial reboot in which their saved states were re-opened?...

I quit Companion on both Macs, re-launched it, got the pop-up asking to allow Local Network access, granted access, and now Companion appeared in the list of apps in System Settings > Privacy & Security > Local Network. So my client's ATEM Television Studio 4K8 is now connected to Companion on both Macs. (I'm running 2 Stream Deck XLs - one for each Mac - to set presets that control the ATEM (with 4 BM Studio 6K cameras + 2 teleprompters), H2R Graphics, and Lightkey DMX lighting (with 4 GVM Pro sd300b and 2 Godox TL120 RGB tube lights).

Elgato Stream Deck only appeared on the list of apps in System Settings > Privacy & Security > Local Network after rebooting. Quitting the app and re-launching it did not work like with Companion.

I originally installed Companion and Elgato Stream Deck last month and I would imagine I would have allowed Local Network access when asked, but I don't remember.

I do have the setting in Companion enabled so it launches on startup. I wonder if that is a factor somehow with this particular chip set? I'll experiment with these 4 Macs in 2 studios and see what happens and keep you posted here. So far, leaving it enabled and rebooting continues to work without having to toggle the Local Network access setting... 🤞

What an annoying bug!

[Julusian]

One thing I am wondering, where do you have the companion app on your machine?
Maybe that has something to do with this?

I did notice yesterday that if I ran companion directly out of the downloaded dmg, it would disappear from the settings upon reboot, but if I copied it to applications and ran it from there then it would be remembered

[alexmarshall37]

One thing I am wondering, where do you have the companion app on your machine? Maybe that has something to do with this?

I did notice yesterday that if I ran companion directly out of the downloaded dmg, it would disappear from the settings upon reboot, but if I copied it to applications and ran it from there then it would be remembered

I've only ever run it from Applications.

[meonlylouder]

One thing I am wondering, where do you have the companion app on your machine? Maybe that has something to do with this?
I did notice yesterday that if I ran companion directly out of the downloaded dmg, it would disappear from the settings upon reboot, but if I copied it to applications and ran it from there then it would be remembered

I've only ever run it from Applications.

Same. I never ever run apps other than installers from a disk image.

[Julusian]

hmm ok..

logged in as adminstrator or standard users?
ever change user account on the macs?

companion set to run at login, launched manually, or with the 'restore windows at startup' thing?

any mdm in use for the macs?

anything else different about how the macs are setup? my setup is essentially a fresh personal mac. it could be anything messing with this, so the more detail about what could be different from that setup the better.

[alexmarshall37]

hmm ok..

logged in as adminstrator or standard users? ever change user account on the macs?

companion set to run at login, launched manually, or with the 'restore windows at startup' thing?

any mdm in use for the macs?

anything else different about how the macs are setup? my setup is essentially a fresh personal mac. it could be anything messing with this, so the more detail about what could be different from that setup the better.

This particular instance is on a client computer, but I had full admin privileges. Program only running when I opened it. The issue seems to be 100% due to the Sequoia security features. Until a workaround is found, I don't think anyone should upgrade, or if you have, I haven't seen anything that shows consistent successful connectivity.

[Julusian]

I don't think that we should say that noone should upgrade, but be prepared to downgrade or deal with the workaround.

For context, it looks like about a third of macos users of companion are running some version of 15. Which is a significant portion, so its not a universal issue but affects a minority of users.

[alexmarshall37]

I don't think that we should say that noone should upgrade, but be prepared to downgrade or deal with the workaround.

For context, it looks like about a third of macos users of companion are running some version of 15. Which is a significant portion, so its not a universal issue but affects a minority of users.

People are free to do whatever they want, but it's a huge pain to downgrade, so folks should know the consequences for updating. I'm just saying what I've done. I also have personally tried every workaround I've seen and NONE worked on the latest version of OS 15 to a degree where I trust it.

Until Bitfocus finds a way that will work with ALL of OS 15, or Mac puts out an update that doesn't break every connection. I'll be staying on Sonoma.

[meonlylouder]

hmm ok..
logged in as adminstrator or standard users? ever change user account on the macs?
companion set to run at login, launched manually, or with the 'restore windows at startup' thing?
any mdm in use for the macs?
anything else different about how the macs are setup? my setup is essentially a fresh personal mac. it could be anything messing with this, so the more detail about what could be different from that setup the better.

This particular instance is on a client computer, but I had full admin privileges. Program only running when I opened it. The issue seems to be 100% due to the Sequoia security features. Until a workaround is found, I don't think anyone should upgrade, or if you have, I haven't seen anything that shows consistent successful connectivity.

These client computers I'm working on so far have not had any of the corporate security mess installed yet - just set up as brand new personal Macs as if I were going to use them in my own home office (just like my personal M1 MacBook Pro). Only the single admin user. Companion is set to load on login, as well as "restore windows at startup."

They are wanting to install their "basic security stuff" this week and I'm expecting more problems at that point.

Unfortunately, these brand new machines purchased Dec 2024 already had macOS 15 installed. "Don't upgrade" is not helpful for many of us. And downgrading is not something I personally would recommend my client do.

I just tried a 2nd reboot since the 15.1.x to 15.2 upgrade this morning. Companion was still able to access the ATEM after the 1st reboot, but it was "connecting" after this 2nd one. Can confirm that the toggling of Companion's access setting in System Settings > Privacy & Security > Local Network DOES immediately re-establish the connection. Same exact behavior on both machines set up the same, both connected via ethernet directly to the ATEM Television Studio 4K8's internal switch, which is connected to the building's internet/router.

Thanks for this helpful thread! Let me know if there's anything else I can test on these systems to help find the fix - IF there is one that can be done on Companion's side.

Are other apps/controllers besides companion having this same issue with these new M4 Macs running macOS 15?

Marcus dePaula

[Lukeb873]

So @meonlylouder to be clear, you're having the same issue originally described on these M4 Pro Macs, correct? Even after the most recent Sequoia update?

Until a workaround is found, I don't think anyone should upgrade, or if you have, I haven't seen anything that shows consistent successful connectivity.

For those of us buying new mac minis (M4), you can not downgrade from Sequoia. The chipset isn't supported on Sonoma. On old M1, M2, M3, or intel machine that have been update to Sequoia, you can downgrade, but it's a giant pain in the butt to role back OS updates.

logged in as adminstrator or standard users?

Admin

ever change user account on the macs?

Nope!

One thing I am wondering, where do you have the companion app on your machine?
Maybe that has something to do with this?
I did notice yesterday that if I ran companion directly out of the downloaded dmg, it would disappear from the settings upon reboot, but if I copied it to applications and ran it from there then it would be remembered

We also put Companion in applications and have it run at login.

As far as IT management, we have a "Production" set up, so full admin access to our machines with no limitations and 1 account. There's no IT bloatware besides our self-service application for installing SSID passwords, printers, or managing OS updates. It also assets our machines and tracks locations. They put Microsoft Defender on them, but we've never had an issue with it blocking companion before and just to be certain this wasn't the issue, I turned it off, and even further than that, I had them fresh install Sequoia with NO IT management whatsoever, and had the same issue with Companion.

For context, it looks like about a third of macos users of companion are running some version of 15. Which is a significant portion, so its not a universal issue but affects a minority of users.

This is what I'm curious about and why I want to ensure that Meonlylouder is having issues on M4 chipsets. It's been fine on the M1 and M2 that I've tested. We just got quite a few M4 minis in today, but they need to get asset tagged before I can do any testing with companion. So far, I've only seen the issue personally on Intel minis running Sequoia. I'm also curious @Julusian, a third of MacOS users are running 15.x, but how many care enough to look at the GitHub or go as far as to create an account to add to this thread. Some might just see the bug and be like, cool they're aware and there's active discussion. Also, M4 has only been out for a very limited amount of time. Our (10) M4 minis we ordered about 2 months ago just came in today. There's likely very few companies with M4's ready, and even fewer that would care to look at the GitHub. I would take a pretty good guess, most of those MacOS users you see running 15, are users with M1, M2, or M3. M4's are just getting into the wild. Intels are pretty rare because they lack so much performance compared to M1 and especially compared to M4, so most people don't have them. We only have them for small random things like this that don't need performance.

Are other apps/controllers besides companion having this same issue with these new M4 Macs running macOS 15?

Not to my knowledge. When I get the M4's back from out IT department next week, we're gonna test Pro Presenter NDI output and some Dante Virtual Soundcard stuff.

[meonlylouder]

@Lukeb873 Yes, these are all M4 Pro Mac minis purchased Dec 2024. The bug does not appear on my personal M1 Pro MacBook Pro.

[Lukeb873]

Copy that. I was able to verify this on our standard M4's today. It works fine after cycling that local network permission, but just can't hold after a reboot. Using the same config as my original screen shot, the M4 crashed the exact same way. I guess our server is living on an M2 Pro for now

[fbella69]

After a ton of experimenting, testing, and research on many other forums over the last 2 days, we have found that this is a bug in all versions of Mac OS 15.x (Sequoia). It is not related to any particular processor, and it happens on many different macbooks that we have. It occurs when you are using a devices software to access the device on a local LAN. We found it to affect Streamdecks on Companion, BMD ATEM switchers and routers, DANTE sound cards - just about everthing accessed via a LAN address - but only those assigned a FIXED IP address. When the app is first opened in Sequpia - it asks to accept the software as allowed on the local network and places it in the local network list and turns it on. BUT - even after accepted and placed as active on the list - on subequent boots - the app is either not allowed or has constrained access on the LAN. The remedy that worked everytime for us was suggested on this Forum, and that is to go to Privacy&Settings>Local Network - and turn off all the apps, close the pane, reopen it, and turn them all back on. Worked for us everytime. This does not seem to occur with devices connected via DHCP - only fixed IP addresses. That is why not everyone is seeing the issue. Apple needs to fix tjhis and fix it FAST.