Windows Task Scheduler and OBS

[chegele]

Hi all,

Needing some help with a specific use case and a problem I've run into.

OBS running on Windows 11 desktop environment in an "always on" configuration and remote control: church stream run by a volunteer from their phone, no tech person on hand.

Have run into occasional issues with audio spontaneous stopping its flow from the audio interface through OBS. A simple reboot of OBS restores audio.

I suspect some power saving "features" in Windows being the culprit -- cutting power to the USB port when the computer is not used for a long time. I've gone ahead and disabled the permission for Windows to turn off USB devices to save power in device manager. But as an additional failsafe, I want to automate Windows ending OBS and restarting it early Sunday morning so it's fresh for a service.

The most obvious way to do this is using Task Scheduler. When testing this out manually, I was able to kill OBS using a batch file to run taskkill, and able to restart it by correctly configuring OBS to "start in" the right directory. This process also worked when scheduling the kill task to run 5 mins and the launch task 6 mins in the future. l

So I set both tasks to run at 5am and 5:01am respectively this morning. However, this morning, it was found that OBS was killed successfully but did not start again successfully, so I had to walk the volunteer through a manual start of OBS.

Any idea why the OBS restart task might have failed when it succeeded in testing? The only difference I can think of is that Windows had locked itself (but did not log the user out) during the time the task was scheduled. Would this have made a difference for OBS being able to start?

I know I can simply disable locking (or even password protection altogether) on Windows to ensure there's always a running desktop when the task is called. But that seems foolish from the perspective of OpSec. I suppose I might instead try to relaunch OBS (after a delay) using the same batch file that I use to kill it -- are there any command line arguments to force the program to launch for the user even when the desktop isn't active?

I'm a bit out of my depths here. So any help will be appreciated. The last resort is to train volunteers to either start or restart OBS or the whole computer manually. But I'd really like to get this automation to work.

 

[chegele]

FWIW Task Scheduler reported the task failed with code 0x800710e0

 

[chegele]

A quick update:

I condensed both tasks into a single batch file to taskkill obs, timeout for 1 minute, then relaunch OBS. Again, this worked in testing, both as a manual launch and as a scheduled event running a few minutes in the future. But after setting Task Scheduler to call the batch file overnight, OBS was again successfully killed but did not re-open as expected. So I know the issue isn't with Task Scheduler per se, but with how I'm calling OBS to run? (I'm using the cd and start commands in the bat without any other arguments). If I knew how to log events from the .bat, I could set that up for more troubleshooting.

Any assistance would be appreciated. Again: Windows 11 Home, can't get OBS to start using Task Scheduler once the computer locks

 

[koala]

That's correct. OBS isn't able to start behind the Windows lock screen. It's a Windows thing. While the lock screen is active, OBS isn't able to access the GPU, so it isn't able to start.

It's difficult to understand there is no person able to stop and start OBS. It's better anyway to start OBS only if it's really being used. On start, OBS initializes all devices and network interfaces it does access. If OBS was started hours ago, then stayed idle, anything could happen to all the connected devices. If someone disconnected a cable and reconnects it again without telling anybody, a new initialization from OBS might be required and nobody knows about it.

 

[chegele]

Thanks, Koala. I thought that I'd be able to get this to work after reading guides recommending Windows Task Scheduler to start streams on schedule by calling OBS with the --start-streaming argument. I suppose on such systems, locking is simply disabled?

Looks like we'll have to build a manual OBS restart into the Sunday Morning routine. A little extra training but ultimately not a big deal. Our priest just really wanted the system to be as automated as possible, so I wanted this to work from the standpoint of optics.

That's correct. OBS isn't able to start behind the Windows lock screen. It's a Windows thing. While the lock screen is active, OBS isn't able to access the GPU, so it isn't able to start.

It's difficult to understand there is no person able to stop and start OBS. It's better anyway to start OBS only if it's really being used. On start, OBS initializes all devices and network interfaces it does access. If OBS was started hours ago, then stayed idle, anything could happen to all the connected devices. If someone disconnected a cable and reconnects it again without telling anybody, a new initialization from OBS might be required and nobody knows about it.

Thanks, Koala. We'll build a manual OBS restart into the morning