That's the way the vast majority of software is. Especially under the hood. If all the required resources aren't available when something starts, it gives an error and gives up right then and there. Sometimes it doesn't even give an error, and the developer has to figure *that* out.
Waiting around for all of those resources to be available, and "just working" after that, takes an explicit effort from the developer(s), in every individual case separately. Somewhat like the option in your web browser to "Refresh Every X Seconds", instead of just giving you a 404, but often harder than that because something else already wants this thing that is waiting, etc., and it completely messes up the timing.
Much easier to just check once and say, "it's not here," and let everything else work with that definite and immediate answer. Then if the user wants to refresh later, after everything's settled down, that's a little bit easier than constantly looking.
---
I have a browser source, for example, that looks for a phone app:
- If I start the phone app and then start OBS, the browser source shows immediately.
- If I start OBS first, and the app isn't started yet, the browser doesn't show. If I then start the app, it still doesn't show. If I then refresh the browser source, *then* it shows.
Likewise for a different, rather complicated rig, that I do start with a script and not manually. Most of what OBS relies on there, is not running by default, and it just gives up if it's not there on the first check. So the script sets all of that up, *then* starts OBS, waits for my OK to teardown, and works back out of everything in reverse order to leave the system exactly as it was to start with.
Again, that's completely normal and expected.
Start the basic resources first, then the things that use them, then the things that use that, etc. Teardown in the opposite order.
