Skip to content

Conversation

@Xanacas
Copy link

@Xanacas Xanacas commented Nov 19, 2024

With this Pull Request, there are two changes coming:

  1. I've added Source Transformation to the features. The idea behind this is to be quickly while streaming being able to adjust my sources position and zoom level. Tested on Windows, works well!
  2. I've fixed the bug that resets OBS Websocket Settings on every startup of loupedeck. Cause of that issue is, that OBS Studio deletes the section in the global.ini on startup and shutdown. Therefore the config was from plugins perspective always dirty and a new set of settings as been generated- as Connection Settings were not saved within the Loupedeck Plugin, this was even needed. To address the issue, once we have a working set of settings, I save them to the plugin store. If they get outdated, I reinitialize a new set of settings from the OBS Ini.

I'm really sorry for everything that I might made wrong, this is my very very first open source contribution and the first non-school c# project I've ever worked on 🙈🙏🥳

@Oleksandr-Podranetskyy
Copy link
Contributor

@Xanacas How about splitting this PR into two parts: Source Transformation and OBS Websocket settings? This way, we can avoid blocking some changes due to delayed review or testing of others.
Thanks.

@Xanacas
Copy link
Author

Xanacas commented Nov 25, 2024

Sure, Just let me know, How to do this. 😅

and as i am already working on it. Are you okay with removing obsIni in total and replace it with an individual Plugin config?

@Oleksandr-Podranetskyy
Copy link
Contributor

Sure, Just let me know, How to do this. 😅

and as i am already working on it. Are you okay with removing obsIni in total and replace it with an individual Plugin config?

We can achieve this by separating the changes related to the OBS WebSocket into a new pull request and removing those changes from the current one. As a result, we will end up with two pull requests: this one will contain only the changes for Source Transformation, while the new one will include only the WebSocket changes.

We are going to investigate the issue with the connection to the OBS WebSocket to identify all instances where it occurs. While some people experience this issue, others do not, and we need to understand why. Additionally, we need to conduct a deeper investigation to assess the priority and seriousness of the problem.

@Xanacas
Copy link
Author

Xanacas commented Dec 2, 2024

@Oleksandr-Podranetskyy
I've investigated a lot in the websocket thing. The issue is really simple:
OBS deletes all the websocket settings in its own config, once it started using the settings.

My suggestion is, we implement an individual setting.json for the plugin and get completely rid of the obsini stuff. I've already started with this. Just need a bit feedback, if it's okay if I go this way.

@Oleksandr-Podranetskyy
Copy link
Contributor

@Oleksandr-Podranetskyy I've investigated a lot in the websocket thing. The issue is really simple: OBS deletes all the websocket settings in its own config, once it started using the settings.

My suggestion is, we implement an individual setting.json for the plugin and get completely rid of the obsini stuff. I've already started with this. Just need a bit feedback, if it's okay if I go this way.

The plugin interacts with the OBS INI file to:

  • Enable the OBS WebSocket if it is disabled.
  • Read the OBS WebSocket password to connect to the WebSocket. For example, if OBS changes the password, the plugin needs to know it to establish a connection.
  • Set the OBS WebSocket password if it is not already configured.
    It seems that the plugin still needs to work with the OBS INI file.

What are your thoughts on this?

@Xanacas
Copy link
Author

Xanacas commented Dec 2, 2024

@Oleksandr-Podranetskyy
I know, but this originally good approach does harm more than it helps benefitting with OBS deleting those details on every startup/close of obs.exe
Means in current obs versions, the plugin is never able to read the configuration from the OBS Ini file, because they are never there.
For the plugin it always looks as if the websocket server is not yet configured, so it reconfigures it. means it destroys the exsting configuration which is probably also used by different tools like streamer bot, companion, mobile apps etc.

In addition to this, the password that is currently created includes lots of special chars - however if I look the password up in OBS, it is displaying the special chars as URI-encoded. Means it gets even harder to simultaneously use loupedeck with other tools that make use of obs websocket server.

The changes I made in this PR towards the websocket thing are the following:
I'm saving username and password within the plugin store and ignore the missing entries in the OBS INI in case I am able to connect with those credentials. If the credentials are wrong, but the server is up and running, the plugin falls back into old behaviour: writing new credentials to the ini and asking to restart obs. (with all the consequences mentioned above - but it was for me the least invasiv changes to the plugins codebase to fix this)

I'd like to go a step further now:

  • OPTIONAL: check if the OBS INI has Websocket credentials read it and write it to the plugin store
  • create an empty/placeholder config in the plugins directory (if we drop obs ini support or ini does not contain credentials)
  • point the user to that config via plugin status message (+ provide instructions where to enable and find credentials within running obs instance)
  • user then updates the config with their values from within OBS
  • read the config and try to connect to websocket server
  • once connection has been successful, store credentials in plugin store and replace password with ****** in config file (for security reasons)

Step two (I'm happy to then open another pr if needed:) )

  • allow a server url and port in the plugin config to also connect to a remote websocket obs server
  • change the plugin to not only try to connect if OBS is running (if a remote server address is configured)

@Oleksandr-Podranetskyy
Copy link
Contributor

@Xanacas
Thank you for such detailed information. It will be very helpful in internal testing of this issue.

@Oleksandr-Podranetskyy
Copy link
Contributor

@Xanacas The root cause of the issue with OBS WebSocket settings is that the settings are now stored elsewhere, not in the OBS INI file. To resolve this issue, it seems we simply need to read and write these settings from and to the new location.

@Xanacas
Copy link
Author

Xanacas commented Dec 2, 2024

@Oleksandr-Podranetskyy
I've not find anything official on these details. As OBS still reads the values from there, I think the reason for this changed behavior is for security reasons. I doubt (but don't know) that we can still get access to where these credentials are stored.

@Oleksandr-Podranetskyy
Copy link
Contributor

@Oleksandr-Podranetskyy I've not find anything official on these details. As OBS still reads the values from there, I think the reason for this changed behavior is for security reasons. I doubt (but don't know) that we can still get access to where these credentials are stored.

We can find this information here - https://github.com/obsproject/obs-websocket/blob/eed8a49933786383d11f4868a4e5604a9ee303c6/src/Config.cpp
This line:
#define CONFIG_FILE_NAME "config.json"

@Xanacas
Copy link
Author

Xanacas commented Dec 2, 2024

@Oleksandr-Podranetskyy
I couldn't find any insides on when exactly or why this has been changed on the OBS side. I think most likely with v28. when websocket became an first party plugin and officially part of obs.

My assumption is, that the removal of the credentials from the obs ini is due to security reasons. Not storing the websocket credentials permanently in a plain config file seems to be a valid reason. However, therefore I doubt, that we can read it somewhere else easily.
Moreover, this would still prevent us from enableing a solution to connect to remote obs websocket instances.

as mentioned earlier, if you're okay with my suggested path, I'll gonna implement it.

@St0l3nID
Copy link

St0l3nID commented Jan 7, 2025

I dont quite get why cant have a solution where we enter the password ourselfs on Loupedecks side. Its not like we change passwords every day, quite the opposite. All other programms that use the websocket have the password stored in some way, loupedeck is the only one that tries to automate the process and during that, screws it up.

@Sixthcrow
Copy link

@Xanacas are we still waiting on an update for this? Noticed I'm still dealing with either Loupedeck or StreamerBot working. Just wondering if there is any sort update. Thanks

@LegendMarek
Copy link

Is this still being worked on or does anyone have any ideas how I can finally connect Loupdeck and Streamer.bot to OBS at the same time?

@St0l3nID
Copy link

Not only is still an issue, the OBS plugin now regulary uninstalls itself too....
Loupedeck really gotta step their game up.
@LegendMarek you can open obs, which will randomize the auth. Then simply go to the websocket setttings, disable auth and connect the bot.... It works but its stupid and if you have more then 2 its a real pain to get all of them working.

@Sixthcrow
Copy link

@St0l3nID I've recently switched over to Meld, but remember having this issue on OBS too. Funny thing is shortly before I switched I could have sworn it was working again. So I booted up my OBS profile, streamer bot and opened loupedeck again, and it all connected. Loupedeck 6.2.1.160, OBS 31.0.3, Streamer bot 1.0.1. I did have to update the IP information for the websocket connection in Streamer bot, I had changed my router in the last month, but ya, Streamer bot and Loupedeck are both connected and commands work too. I'd just double check your settings in case something did change during an update or something. Maybe a firewall is getting in the way? Who knows.
Also, I do have authentication on, so shouldn't need to disable it.
Anyways, I think it is fixed because I was having the issue and after an update it just worked. So might be something on your local setup that could be causing the issue.

Good luck.

@St0l3nID
Copy link

I'm on the newest version of OBS, Loupdeck and the plugin. Loupedeck randomises the OBS websocket password everytime it connects to it, which it will only do once, if i have to restart obs, loupedeck needs to be restarted before it. And to get a connection reliably you have to have loupedeck open, open obs (password gets randomised) and then connect the other apps somehow (by either disalbing auth or giving them the new password). This, frankly, stupid behaviour is consistent and reproducable.

@Sixthcrow
Copy link

@St0l3nID that doesn't sound quite right. Like I mentioned I haven't opened OBS for a bit, but when I did, Streamer Bot and Loupedeck both connected. I haven't changed the password for that setup in who knows how long, but it was still the same password. I just updated my IP because of the router replacement as I mentioned before. My first thought would be Loupedeck is somehow corrupted or maybe an update didn't apply the fix? I'd try uninstalling loupedeck first, after backing up your profiles of course. And then reinstall and see. But try to look through your appdata to make sure it's all cleared out. Just really weird I had the same issue, but it's fixed, yet it's still ongoing for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants