Feature request: change item visibility globally (current scene)

[ASchneiderBR]

Hello @WarmUpTill !

Do you think it would be possible to add an option to the action Scene item visibility to be able to choose a source globally? This could be also achieved with a Current scene option (or Any) :)

This would help a lot to change an item visibility, in my case, to restart a media source, on all scenes that this media source is present.

Enabling or disabling a source does not restart a media source, it just hides the source globally and keeps it running in the background.

Thanks!

[WarmUpTill]

Thanks for the suggestion! I will add it to the todo list :)

[WarmUpTill]

I implemented the possibility to select "current scene" for the scene visibility action with the linked PR. (Sorry that it took so long) Let me know if it work as expected and I will add it to other actions where it makes sense also. :)

[ASchneiderBR]

Amazing! I’ll give it a try and let you know ASAP. Thanks!

[ASchneiderBR]

Hello!

I give it a try and could not figure out how it works, sorry.

I thought that you could see all sources available globally and choose what source you want to hide/show on the current scene (Number 3).

Quick suggestion: maybe you could rename the action (Number 2) the same as the trigger (Number 1), just Current.

Thanks.

[WarmUpTill]

Hm strange maybe I made an error / forgot some corner case. Usually the "Current Scene" selection should display the scene items on whatever scene you are currently on.

I assume the scene you are currently on is not empty, right? Was the plugin maybe stopped while you were checking the entries?

[WarmUpTill]

I now pushed a few changes to the linked PR which should allow all scene items of all scenes to displayed when selecting "current scene". That is probably more in line what users would expect. A build should be ready in a few minutes.

Quick suggestion: maybe you could rename the action (Number 2) the same as the trigger (Number 1), just Current.

What is your reasoning for this? I would have thought it is more uniform the way it is right now. (If current scene is Testes / On current scene hide ...) Just trying to understand - not trying to dismiss your suggestion of course :)

[ASchneiderBR]

Hey there!

I assume the scene you are currently on is not empty, right?

Yes, you are right, not empty.

Was the plugin maybe stopped while you were checking the entries?

Yes, it was stopped at the time.

What is your reasoning for this?

No problem :) Just because in the trigger it is: IF -- SCENE -- CURRENT, as it is now, the action is THEN -- SCENE ITEM VISIBILITY -- CURRENT SCENE. I think since it is stated that the action is "SCENE" item visibility, "ON" something, it could only mean a scene so maybe the just stating "CURRENT" would be sufficient. This is really nothing, just something that crossed my mind when reading.

No worries, it looks awesome as is :)

I'll give it a try ASAP.

Thanks!

[ASchneiderBR]

Hello! I'm not sure that I could find the latest Windows build to download... I've only found Linux version. Thanks.

[WarmUpTill]

You can find all builds - including the windows one - here for the linked PR: https://github.com/WarmUpTill/SceneSwitcher/actions/runs/961783767 (The GitHub actions overview can be a pain to navigate sometimes :D)

[ASchneiderBR]

Judging by the title and release date, I thought this was the build with the fix to show all scene items https://github.com/WarmUpTill/SceneSwitcher/actions/runs/961784000

[WarmUpTill]

The action run you linked was just a linter checking the formatting of the code.

The easiest way to find the correct build usually is:

1. Click on the linked PR

2. At the bottom click on "show all checks" and then click on any of the build jobs' details.

3. Click at the top section to reach the summary screen and get access to the build artifacts.

But in future I will try to remember to link to the correct build directly in my comment!

[ASchneiderBR]

Thank you very much for the info! I really need to learn more about GitHub... Thanks!

[ASchneiderBR]

Hello!

I think something broke here with the latest build...

A previously working macro does not work anymore. It was supposed to stop itself after triggering and enable another one. This other one also stops itself and starts the previous one, so it act like a switch to only run it once.

I'm attaching a txt file when I was not streaming:

2021-06-26 18-41-12.txt

[Edit] It seems that current scene item visibility is working after all, sorry. The problem is just with the previous scene trigger.

Here are my settings backup:

BKP.txt

The problematic macros are the ones called beat saber entrando/saindo.

Do you need anything eles?

Thank you.

[ASchneiderBR]

I've also tried changing to a count system, so both macros can be enabled at the same time and reset each other counter number to only run once and still no luck. I think there's something with the previous scene trigger.

[ASchneiderBR]

Hello! This build is actually crashing my OBS, not sure why, just to let you know :)

[WarmUpTill]

Thanks for the test! Can you please also share the crash log?

[WarmUpTill]

I think I have identified the issue regarding "previous" scene selections. A build will be available here in a few minutes: https://github.com/WarmUpTill/SceneSwitcher/actions/runs/976084906

Not sure what could have caused a crash though.

[ASchneiderBR]

Hello!

Previous scene is now fixed, thank you.

There's now a problem with CPU usage and OBS hang when the macro is checked. The moment I start the macro system, my CPU goes from 2% to 6% of usage, when the trigger is checked (I've set to 3000ms), OBS freezes each time it checks for triggers. I think this was the problem before, since I've set it to 500ms and OBS just becomes unresponsive.

I don't have a crash log because I had to alt+F4 to force close it, I think it never actually crashed.

Here's my latest log:

2021-06-27 12-46-27.txt

Thank you!

[WarmUpTill]

Unfortunately I cannot seem to be able to reproduce the problem on my end. :(

Sorry for asking this, but can you somehow narrow it down to what exactly triggers the freeze? Is just one particular macro entry? (Can you try deleting them one by one and check if the issue still persists?) Does it only happen if you interact with the settings window?

[ASchneiderBR]

It happens with or without macros checked or settings window open. It happens when the macro system is active. Here's a quick video showing it. You can see the window freezing when I drag it, also CPU usage.

https://user-images.githubusercontent.com/25224882/123553819-c4444d00-d753-11eb-87a4-e2b280b3a4ef.mp4

[WarmUpTill]

I see - so you are not referring to spikes in CPU usage leading to some sort of stutter, right?

I originally understood it as that OBS would just completely lock up as soon as you start the scene switcher. I thought I somehow introduced some sort of resource leak due to the following line in your log 12:50:59.749: Number of memory leaks: 112. Do you always see this log or was this introduced with this change?

Does the behaviour improve if you delete any particular macro entry? If so which one? (Make sure to back up your settings first though so you can restore the macro)

And just to clarify: This behaviour was introduced with the introduction of the option to select "current scene"? Or is this just a general performance issue that already existed previously?

Thanks again for helping me understand what is going wrong here!

[ASchneiderBR]

Hello, I’ll give it a try. This stutters happens only with the macro system running, all macros were unchecked, so I assume none were actually running, right?

Yes, this behavior started after the current scene option.

[WarmUpTill]

Thanks!

This stutters happens only with the macro system running, all macros were unchecked, so I assume none were actually running, right?

Checks are still performed but actions are not executed. So the issue might be in one of the macro checks.

[WarmUpTill]

If you cannot identify the macro which is causing this stuttering please try running the following build: https://github.com/WarmUpTill/SceneSwitcher/actions/runs/976794899

This should introduce a log if a macro condition check takes longer than 100ms to execute. For example: [adv-ss] spent 131 ms in file condition check of macro 'Macro 1'!

Sorry again for causing this much extra working. I am just not sure what broke here.

[ASchneiderBR]

Hello, no problem! I'm glad I can help in some way...

I've tested deleting macro by macro while the plugin was running. Stutters only ceased after the last one was deleted. Also, stutters was less and less strong each time I've deleted a macro.

I think the problem is not related to a specific macro.

This is the log from when I've started the plugin and then deleted each macro one by one. https://pastebin.com/Sez3xTf8

I'm waiting for the compile to finish to test the latest one.

Thanks.

[ASchneiderBR]

OK @WarmUpTill , it seems that these stutters and OBS not responding only happens when verbose logging is on... Can you test it on your side? I also have the real time log window opened... Turning it off here fixes those problems. Using it with verbose on and about 500ms checks, OBS just becomes unresponsive and unable to click on anything.

[WarmUpTill]

Yes, that seems to be it! I guess the "Log Viewer" tool just can't handle this many traces at once. Thank you so much for figuring it out - I was so confused what could have possibly introduced this issue! :)

I almost always have the verbose mode enabled for development but never use the "Log Viewer" tool as the debug output is printed in Visual Studio anyway, so I have never noticed this before.