Ошибка в обс could not find locale ini path

This comment was marked as outdated.

Please try without the following third party plugins, which may be conflicting and/or outdated:

11:47:04.987:   Loaded Modules:
11:47:04.987:     spectralizer.dll
11:47:04.987:     obs-websocket.dll
11:47:04.987:     obs-gstreamer.dll
11:47:04.987:     advanced-scene-switcher.dll

Nope — no different. I’m pretty sure they have absolutely nothing to do with this issue.

This comment was marked as outdated.

I cannot reproduce this on a clean 27.2.4 OBS version running on Windows 10.

That’s surprising! I can reproduce it each time, on 2 different systems…. I’m happy to blow my installation away totally and just try StereoTool alone with no other plugins being installed.

Can you confirm you’re saving a preset within StereoTool then loading it — then going to Settings ?

Yep, clicked Save, then clicked Load. You can test without the third party plugins without blowing away your installation, just download the portable ZIP of OBS available on the website.

Yep, clicked Save, then clicked Load. You can test without the third party plugins without blowing away your installation, just download the portable ZIP of OBS available on the website.

Ok — So I did this and the issue occurred still…..Can you try this?….

1. Remove the filter / VST plugin from the source.
2. Add it back in
3. Open StereoTool interface
4. Goto ‘Configuration’ section and then click the ‘Preset’ button, under Generic Presets load the top one (Mathijs Vos & Hans …..»
5. Click Save — save all settings
6. Click Load, load all settings and select the file you just saved in step 5.
7. Close StereoTool etc, goto ‘Settings’
8. Issue should now be reproduced (I hope!)

Aha, confirmed. I’m not 100% sure if the code is on the obs-vst side or on the OBS Studio side, but I’ll mark it as confirmed and will revisit later. Please update the original issue description with the confirmed reproduction steps.

Great — got there in the end! Have updated the issue description.

This sounds like a DLL (probably StereoTool) is changing the current directory of the process which is bad behavior, the process is responsible for its own directory. Per MSDN:

The current directory is shared by all threads of the process: If one thread changes the current directory, it affects all threads in the process. Multithreaded applications and shared library code should avoid calling the SetCurrentDirectory function due to the risk of affecting relative path calculations being performed by other threads. Conversely, multithreaded applications and shared library code should avoid using relative paths so that they are unaffected by changes to the current directory performed by other threads.

I have for some time wanted to avoid OBS depending on the current directory, perhaps this is the motivation to do so :).

This sounds like a DLL (probably StereoTool) is changing the current directory of the process which is bad behavior, the process is responsible for its own directory. Per MSDN:

The current directory is shared by all threads of the process: If one thread changes the current directory, it affects all threads in the process. Multithreaded applications and shared library code should avoid calling the SetCurrentDirectory function due to the risk of affecting relative path calculations being performed by other threads. Conversely, multithreaded applications and shared library code should avoid using relative paths so that they are unaffected by changes to the current directory performed by other threads.

I have for some time wanted to avoid OBS depending on the current directory, perhaps this is the motivation to do so :).

Yep you are spot on! I used Process Explorer to check the ‘Current Directory’ of OBS and after loading a preset, this gets changed to the directory of where the preset file is loaded from.

At least I have a workaround now (I can put the preset file we load into the OBS bin directory and load from there).

Hey Hans,

I believe if you do implement that, it should resolve the issue here — thanks for your input!

Done. I’ve verified it in ProcessExplorer as well, and indeed, while the window is open the directory changes, when I close it it goes back to the original directory. For who needs it: This fix will be available in the next beta build, I expect that to be available tomorrow on our forum.

…well would you look at that.

Turns out THIS is what’s behind the crashes with my Cabbage VST plugin; I was finding it weird that:

• OBS only crashes on reopening
• the actual thread which crashes is the obs-browser one, despite the VST being the culprit (rename/move it and things start working again)
• the logs show an «invalid file» message about an unrelated file that’s still there

I’ll ask around in the Cabbage forums for a way to solve this, then.

Meanwhile — and it’s a moonshot about an entirely unrelated plugin: did it work before 27.2?
Both major virtual background plugins remain broken on Windows for non-CUDA GPUs ever since (kounoike/obs-virtualbg#58, royshil/obs-backgroundremoval#87), and the underlying cause seems to be that they attempt to load DirectML from the wrong place…

Oh! You’re right. I just searched and apparently there were 2 places in the code that could open a file dialog, and I missed the one that’s used here. I just verified it again and before fixing the 2nd one it remained at the wrong value, with the fix in the other place it works as it should.

I think when I tested it before I may have closed the window using Escape instead of actually loading a preset, since that also restores the old working directory. BETA017 will be available in a few hours, new release will come after that if no new bugs are reported anymore.

@notr1ch want to keep this open as a reminder to remove any reliance on the current working dir?

Yeah let’s keep this open until we fix the dependency on the CWD.

r/obs