OBS 32.0.4 Keeps Asking for Re-authentication of My YouTube Account on macOS
Operating System Info
Other
Other OS
macOS Tahoe 26.2
OBS Studio Version
Other
OBS Studio Version (Other)
32.0.4
OBS Studio Log URL
https://obsproject.com/logs/LkMz8vsTCaHOQkk1
OBS Studio Crash Log URL
No response
Expected Behavior
Definitely expect not to log me out each time i open obs
Current Behavior
I’m currently using OBS version 32.0.4 on macOS and I’ve run into an issue where it keeps asking me to re-authenticate my YouTube account every time I start the program. Essentially, the login doesn’t persist between sessions. There are no error messages it just prompts for re-authentication each time.
I wanted to note that this issue did not occur in version 32.0.2, but it started happening in versions 32.0.3 and continues in 32.0.4. I’ve also tried running OBS in safe mode, but the issue still persists even there.
I’m not certain if reverting to version 32.0.2 would solve the problem, but it appearsthat the recent updates introduce it. Just wanted to report this so you’re aware. Thanks for looking into it!
Steps to Reproduce
1. Open OBS 32.0.4 on macOS.
2. Click on Start Stream get prompted (Could not access the specified channel or stream key, please double-check your stream key. If it is correct, there may be a problem connecting to the server.)
3. go to settings re authenticate
4. start stream (works normally)
5. close obs
6. open obs (after few minute or after few hour) get logged out need to re authenticate again
7. close it and open it again and authenticate each time
Anything else we should know?
everything was working good till version 32.0.2, I have noticed this problem in 32.0.3 and 32.0.4, this is previous log url might be help full https://obsproject.com/logs/HryXee9S143xsIuj I’m using MacBook M1 (Mac with apple silicone chip) macOS version 26.2
Didn't know how and where to add this image but after closing obs it shows this on my screen and then issue starts
Tried reverting to 32.0.2 but it shows server failed error so got no option but to get back to .4, this is extremely frustrating please fix the issue
Was confirmed on another user, attached relevant log and crash report.
Was confirmed on another user, attached relevant log and crash report.
I am sorry, I was unaware that this issue had already been reported. Thank you for the confirmation and for looking into this. I hope the issue will be resolved soon.
They were just adding that another user could also reproduce, there is no other issue report at the moment, this remains the primary issue for tracking.
Preliminary investigation suggests that this crash is due to OBSBasic's destructor running recursively when the YouTube browser dock is active (user-created browser docks don't seem to produce the same outcome):
- Shutting down OBS from within the application is implemented as closing the "main window".
- Closing the main window triggers a very bespoke series of events, at which end a
DeferredDeleteevent is scheduled that actually deletes the main window - This leads to the
OBSBasicdestructor being run - As part of the destructor, the destructor for
QList<std::shared_ptr<QDockWidget>>is invoked - Because of the YouTube browser dock, this invokes
std::default_delete<QDockWidget>and thus the destructor ofYouTubeAppDockandQCefWidgetInternal QCefWidgetInternal's destructor callscloseBrowser()(a perpetual bugbear of the app) which runs its own event loop to "wait" for CEF to shut down while blocking execution of the destructor
Because there can only be one event loop active for an application, this event loop will not only wait for CEF to emit its event when finished, but also handle all other application events, one of them being a QMetaCall to QCocoaIntegration::Quit (which just calls [NSApp terminate:nil]).
This triggers the - (NSApplicationTerminateReply) applicationShouldTerminate:(NSApplication *) sender AppKit delegate method implement by Qt's platform plugin, calling QWindowSystemInterface::handleApplicationTermination(), which sends a proper "Quit" event to the QGuiApplication instance.
The aboutToQuit event is emitted, the custom event handler in OBSapp runs and explicitly calls delete on the mainWindow, effectively calling OBSBasic's destructor recursively while the destructor is still pending (blocked by the event loop used in closeBrowser()) and hence will attempt to access already deallocated memory.