Hi, and thanks for the response. No, I don’t have multiple versions of Unity open, and yes the issue persists after a fresh boot.
I have a coworker who’s also using macOS, and he had the same issue. After some troubleshooting, he realized the issue could be fixed by adding 127.0.0.1:9264 as the address to connect to rather than localhost. Seems like this is likely a bug either with FMOD or macOS.
Doing so did allow me to connect to the game (Live Update On in FMOD Studio). However, the Mixing Desk is still not working for me (it works for my coworker). For me, there is no gain monitoring happening, and soloing or muting groups does nothing.
Just for your information, the project and our FMOD Studio versions are now on 2.01.10. FMOD is still logging “[FMOD] FMOD_OS_Net_Listen : Cannot listen for connections, port 9264 is currently in use.” in Unity.
Update: Coworker reports that the mixing desk is working for him intermittently. Seems to stop and start working at random. He says: “The thing I noticed when it started working is that it only shows green in FMOD while play mode is on. When it wasn’t working, it would show green all the time.”
Yes, please find fmod-logs.text attached. This is the console output, filtered for “FMOD”. FMOD Studio was already monitoring for a Live Update connection, and I entered then exited play mode. If you need something else, let me know.
Everything in that log appears to working working as expected, you can see it trying to use port 9264:
[FMOD] FMOD_OS_Net_Listen : Cannot listen for connections, port 9264 is currently in use.
And during this time the Network Utility Port Scan is showing port 9264 as open?
If so, can you please check the FMOD Studio console, under ‘Window > Console’ then go to the logging tab and ‘Show verbose logging’. Then try to connect to the game as you normally would and share that output.
No, the main log I am seeing in the Unity console is [FMOD] FMOD_OS_Net_Listen : Cannot listen for connections, port 9264 is currently in use. It logs every 3-4 seconds.
The only other log I see when entering Play Mode so Live Update can connect is FMOD Studio: Destroying editor system instance. This happens immediately upon entering Play Mode, before the warning starts up about port 9264.
Another update on this. We always restart Unity when switching branches, otherwise Unity may freeze or crash. It occurred to me that switching branches might be completely unrelated to the issue, and perhaps it was closing and reopening Unity that was the problem.
I went through my steps to fix Live Update (deleting all FMOD folders in the project, re-importing the FMOD Unity Integration unitypackage, restarting Unity, re-linking the FMOD Studio Project). After Live Update was working, I simply closed and reopened Unity and Live Update stopped working again.
So simply restarting Unity on macOS breaks Live Update. Any ideas about how to fix this?
Thanks for the update, it sounds like FMOD may still be running when Unity closes, that would cause the port to remain in use. This may be possible to see in the FMOD debug window in Unity, the memory values should be larger the second time you open Unity if FMOD is still running in the background.
Are you able to share the Unity editor logs from when you close Unity the first time, it should be found at ‘~/Library/Logs/Unity/Editor.log’.
Thanks for the response. Happy to provide the log (attached).
The trouble I have with this hypothesis is that Live Update does not work after rebooting my machine. It’s only possible to fix by removing FMOD Unity Integration from the project, then reinstalling it. After that, Live Update works the first time Unity is opened, but not thereafter (until repeating the process of removing it again).
If this issue was caused by FMOD continuing to run after closing Unity, wouldn’t it be fixable by restarting the computer?
One last thing – how can I get to the FMOD debug window? I’m not seeing it. Thanks!
Yes, I have a project I can share. Zipped it is about 266MB. What’s the best way to send it?
In putting this together, I think I’ve found a workaround. We have a Monobehavior which accesses an FMOD mixing group/bus with the [ExecuteAlways] attribute. It seems that removing this attribute fixes the issue.
Please take a look if you can, if only to arrive at solution that saves others from unknowingly running into the same issue (logging a warning, adding it to the documentation, etc.). Or if you can identify a fix, all the better! I’ve attached the project as live-update-issue.zip.