luxifer
New Member
Hi,
just an FYI for whom: I just found out that OculusVR requires the "Quality Windows Audio Video Experience" (qWave) service to run. Now, that service in turn requires parts of the "Link-Layer Topology Discovery protocol" component or else it won't start!
Right now not only is there no dependency mapping between qWave and LLTDP in NTLite, worse it shows the LLTDP and it's parent component - QoS in the "Gaming" template of components ostensibly safe to remove. It'd be nice if that could be fixed - maybe with an additional compatibility option specially for OculusVR.
Cheers
PS: This was a nasty problem to hit because OculusVR will start a "Fixer" tool when the service fails to start, which checks a couple of things and then tries to re-start the service. Since it has no reason to check for a normally mandatory Windows component missing, it doesn't, so it'll think everything is fine and just restart the service. It'll then wait for the service to start to verify that it works, which never happens but instead another "Fixer" instance is started... rinse and repeat within like 2 seconds. Only being very quick at selecting the upcoming processes for both the "Fixer" and the service itself in task manager and killing it as quickly as possible will stop this process...
just an FYI for whom: I just found out that OculusVR requires the "Quality Windows Audio Video Experience" (qWave) service to run. Now, that service in turn requires parts of the "Link-Layer Topology Discovery protocol" component or else it won't start!
Right now not only is there no dependency mapping between qWave and LLTDP in NTLite, worse it shows the LLTDP and it's parent component - QoS in the "Gaming" template of components ostensibly safe to remove. It'd be nice if that could be fixed - maybe with an additional compatibility option specially for OculusVR.
Cheers
PS: This was a nasty problem to hit because OculusVR will start a "Fixer" tool when the service fails to start, which checks a couple of things and then tries to re-start the service. Since it has no reason to check for a normally mandatory Windows component missing, it doesn't, so it'll think everything is fine and just restart the service. It'll then wait for the service to start to verify that it works, which never happens but instead another "Fixer" instance is started... rinse and repeat within like 2 seconds. Only being very quick at selecting the upcoming processes for both the "Fixer" and the service itself in task manager and killing it as quickly as possible will stop this process...
