-
-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release Candiate (RC) suffix on version number breaks macOS DAL VirtualCam plugin version comparison #3838
Comments
cc @PatTheMav @gxalpha are we doing something weird? |
this should have been addressed in 55da44d 🤔 |
Then my guess is if the user updated from rc1 to rc2, the updated DAL plugin may not have been applied. Did we bump the DAL plugin version? |
no, we didn't. |
May be worth bumping it just because for actual release, I think. I assume if the versions don't match OBS will install the newer version? |
After installing via OBS 26.1 rc2:
So this is indeed a fat universal binary. I think this bug is different from what has been resolved in #3779 (i.e., architecture difference).
Looks like the distributed binary has a correct version bumped. |
The plugin is also properly signed:
Could you please run Edit I just checked, the main binary will not have that entitlement, because Chromium doesn't want it for security reasons. Instead the helpers should have it, which - in case of the Apple Silicon build - they do:
|
Small part of the problem might be that the version strings are incorrectly formatted due to the |
@gxalpha If that is the case, manually changing it in the DAL plugin's |
@gxalpha @PatTheMav Bingo! I manually modified |
ok, are we somehow able to give the virtualcam a separate version number then? |
So I just tested it on an Intel Macbook and rc2 works fine without issues. Which means this would only be an actual issue if macOS behaves stricter on M1 processors or maybe just notarised apps. Edit: I'd like to get more clarity on this first, as the current process was chosen to minimise manual versioning/impact for bundling the app. In my tests with non-notarized apps the plugin was loaded fine even with the suffix. In this report I assume we have Chrome and Zoom (both notarised I assume) which do not. @gxalpha could you test this on your machine as well please to rule out an x86/M1 difference? |
On my intel mac, upgrading from rc1 to rc2 did work, with OBS asking me to give permission to overwrite the old plugin and successfully doing so. Virtual camera does still work. Edit: Also please pardon me, it's pretty late and I'm gonna sleep now, so answers might take a while |
In your environments, what was the macOS version? I wonder if it's a Big Sur (11.0) v.s. older OS versions, or a x86_64 vs M1 difference. |
I agree with @gxalpha that it’s probably something about version numbers. @wookayin did you have rc1 installed prior? I’ve definitely experienced issues in the past when trying to install new versions of the plug-in but I forgot to bump the version. You tried rebooting, restarting chrome, etc after installing rc2 before reporting this right? Lots of times a reboot seems to help folks and you generally need to restart host apps after changing the plug-in bundle. |
Big Sur 11.0.1, for everything that I described |
I think your comment and my answer to that belong to #3839 (because it feels like a different issue/phenomenon), but let me write here as the discussion has moved here from #3839 :) So yes, after rebooting, the plugin works and does not crash. Restarting the host apps without rebooting does not help. The scenario is like: (i) have a previous version working (rc1); (ii) Update OBS.app and start virtual camera to automatically install a new version of DAL plugin (rc2); (iii) at this point Quicktime, Chrome, etc. would all crash. (iv) Reboot, then it just works fine. However, my view is that most of general users will run into exactly the same situation as they won't bother themselves rebooting right after starting the virtual camera in a new version. No warnings or messages are shown, and it isn't quite obvious for a lay-user that rebooting is required (regardless of why it happens). All other applications that use cameras will crash silently with no hint about OBS. Should we make an explicit warning or dialogue telling "reboot would be required"? Or is there any good way/workaround to make it not crash? For example, if the DAL plugin directory were completely removed prior to automatic installation of a DAL plugin, it would not crash even without rebooting. Regarding this issue (#3838) per se --- the DAL plugin still won't work on a M1 machine regardless of rebooting, unless the version string is in the required format. |
It might be different on M1 Macs (which I do not have to confirm) but I’m updating the DAL plug-in sometimes multiple times a day without crashes or the need for reboots. So I’m not comfortable with a blanket statement (‘reboots are needed’) as long as we haven’t confirmed the root cause. |
I suspect this is an issue from upgrading from a non-universal plugin to a universal plugin. I bet that upgrading between two universal plugins will work just fine. And since the very first publicly released version of OBS will have a universal binary, normal users won't ever experience an upgrade from a non-universal plugin to a universal plugin and thus shouldn't need a reboot. Perhaps there's something in the OS that's caching the old non-universal version of the plugin binary until you restart -- and then it crashes when it tries to load the non-universal plugin inside an ARM process. Do you have a stack trace in the 'Crash Reports' section in Console.app you can find? I also don't have an M1 Mac though, so I can't be that helpful in testing this hypothesis. |
@PatTheMav @johnboiles I forgot to mention in my previous comment that the segmentation fault bug (#3839) happened in an Intel mac (10.14). (actually on M1 mac too) For stacktrace, please refer to #3839. I also did the exactly same test by upgrading OBS from 26.1 rc2 to 26.1-rc2-df4eb8219 (master snapshot), and this time the plugin loads without crash. I also remember I had experienced the same in an opposite scenario, i.e. upgrade from a universal binary (the third-party virtualcam plugin) to built-in 26.1 rc1 (non-universal). What you hypothesized sounds very plausible and makes sense. I now think that normal users won't experience this once we release a GA version. |
The tricky part is that the DAL plugin is loaded (and maybe even cached) by macOS/client apps themselves, not by OBS. When debugging the virtualcam plugin I had several occasions where Quicktime was one of the candidates which somehow kept the plugin "in memory" and when I deleted it chose to crash until I rebooted (as Quicktime has Library hardening activated in Big Sur that issue is.. well.. not possible anymore). Also Big Sur is using more extensive |
Now that 26.1.0 is properly out on macOS, please update to it, reboot, and see if all issues are solved. |
Congrats! I have confirmed that the virtualcam plugin shipped with OBS 26.1.0 works well as expected on my M1 mac. However, rebooting my mac was necessary (before rebooting, host apps were crashing) after plugin installation and having the virtualcam started; restarting the host app only was insufficient. It would be great to have a fix for DAL plugin versioning though, in order to make any future snapshot/RC versions working. Thanks for the support! |
@wookayin Excellent, thanks for the confirmation. I've updated the ticket title to reflect the actual cause of the issue. |
For me, on an Intel Big Sur Mac. I also had host apps crashing after upgrading from my plugin to the one bundled with 26.1. I removed the plugin entirely ( |
Possibly fixed by #4265. EDIT: Using proper (persistent) build numbers is definately on my to-do list, but not part of that fix. |
Thanks for the fixes in #4265. However, my understanding is that the '-rc' or 'snapshot' version suffix broke the plugin, not library caching issue. I will test this on my M1 mac soon and let you know. |
@wookayin Did you ever test it? |
Since we're now in a RC phase again, it might be worth it to test if this is fixed. I'm not on M1 myself, but people on it should maybe try. Also sorry to everyone that just got pinged, but given that RC phases are pretty rare, testing this to me feels (at least somewhat) urgent :D |
@jp9000 @gxalpha I just tried out 27.0 rc1 (upgraded from 26.1.2) and the virtualcam works well on my M1. As before, I did not manually delete the DAL plugin and installed the new one from OBS (start virtual camera). Without any further actions (e.g. rebooting or manual deleting, the virtualcam worked! Looks like #4265 did the trick. I can see the |
Excellent, thanks for verifying. Closing this issue. |
Platform
Operating system and version: MacOS 11.0 Big Sur (a M1 mac)
OBS Studio version: 26.1.0 rc2
Expected Behavior
The virtual camera plugin should work -- the OBS virtual cam should appear in the camera list.
Current Behavior
The virtual camera DAL plugin shipped with and installed from OBS cannot be used in many applications. The camera list does not show OBS Virtual Camera (other hardware webcams are fine).
I tested with Google Chrome (arm64) and zoom (x86_64+rosetta2) but it did not work for me with either apps.
Logs:
Steps to Reproduce
Trivial.
Additional information
Highly relevant to johnboiles/obs-mac-virtualcam#4. I think one needs to have the binary properly signed. I'd like to note that the obs-mac-virtualcam binary distributed by @johnboiles does not have such issues; it worked well on a M1 mac (with OBS 26.0.2).
The text was updated successfully, but these errors were encountered: