Fallback Handler Could Not Load Library

[Margit Szermer]

The build succeeds when I build my DLL using getCvFrame or getFrame but once I load my application that uses the DLL I get "Fallback handler could not load library" errors. When I don't have these calls everything works as expected.

I see the "This API only available if OpenCV support is enabled" in the API docs but I'm not sure how to "enable" it. From what I can tell in this OpenCV support example, there is nothing done explicitly to enable opencv support.

To "enable" OpenCV, it means you need to have OpenCV installed on your system and it should be properly linked with your program. The OpenCV library files should also be in the system PATH, or in the same directory as the running program.
Here are some steps you might want to consider:

Recently got a new laptop with a Ryzen 7 7735HS and RX7600S. I've been forcing all my games to run on the GPU instead of the APU, but it doesn't seem to be working for DEOVR. It opens a window on the desktop but on Oculus it still shows as loading.
Anyone know of a solution for this? I've updated all my graphics drivers and forced the GPU in windows graphics settings.

Going through the logs I see "Fallback handler could not load library C:/Program Files/Oculus/Software/Software/infomediji-d-o-o-deovr-video-player/DeoVR_Data/Mono/openvr_api.dll" The file doesn't exist, and even after reinstalling it's not there.
Any solutions? Thanks.

Antialiasing: 0
RenderScale: 1.7
VSyncCount: 0
Current system is Windows 11 (10.0.22631) 64bit
Current videocard is AMD Radeon RX 7600S
Current platform is OculusRift
DontDestroyOnLoad only works for root GameObjects or components on root GameObjects.
Initializing Google Analytics 0.2.
SLRAnalyticsController initialized. TrackingCode = G-XYPFYRG2XLDAzk0PnBTKavnQKi47qd4w
Default keybinds for RiftController successfully loaded.
Default keybinds for QuestHandTrackingController successfully loaded.
Default keybinds for RiftRemoteController successfully loaded.
Default keybinds for GamepadController successfully loaded.
[ProjectionMesh] v1.8.1 awakens
Browser initialized.
Camera "Main Camera" does not use a Tracked Pose Driver (Input System), so its transform will not be updated by an XR device. In order for this to be updated, please add a Tracked Pose Driver (Input System) with bindings for position and rotation of the center eye.
Numpad is not supported by this keyboard "Keyboard_PIN"
Numpad is not supported by this keyboard "Keyboard_PIN"
[AVProVideo] No camera set for UpdateMultiPassStereo component. If you are rendering in multi-pass stereo then it is recommended to set this.
Unity v2020.3.42f1, Oculus Utilities v1.89.0, OVRPlugin v1.89.0, SDK v1.0.27.
SystemHeadset Rift_S, API OpenXR
OpenXR instance 0x3C5800000001 session 0x0
Current display frequency 0, available frequencies []
Failed to initialize Insight Passthrough. Passthrough will be unavailable. Error Failure_NotInitialized.
Local Dimming feature is not supported
Found IOVRSkeletonDataProvider reference in RightOVRHand due to unassigned field.
Found IOVRSkeletonDataProvider reference in LeftOVRHand due to unassigned field.
[AVProVideo] Initialising AVPro Video v2.7.3 (native plugin v2.7.0f1-ultra) on AMD Radeon RX 7600S/Direct3D 11.0 [level 11.1] (MT True) on WindowsPlayer
The current MSAA level is 0, but the recommended MSAA level is 4. Switching to the recommended level.
[OVRManager] HMDAcquired event
[OVRManager] InputFocusLost event
Unable to process a controller whose SampleRateHz is 0 now.
Unable to process a controller whose SampleRateHz is 0 now.
[Deo] LoadSettings
ActionController_ChangeDevice GamepadController Any
ActivateReticle
LogFolder created C:/Users/charl/AppData/LocalLow/Deo VR/Deo VR\logtracker_5faff72a-3b5d-4fe6-87cc-aaef79b65862
Loading redirects...
Loading project: DeoVR
[Deo] GetProject: DeoVR
Redirects loaded: 41
[Deo] GetFilters
Set reload method: ReloadMedia
Reloading dashboard: ReloadMedia
[Deo] GetVideos: page=1, perPage=12
[Deo] GetTags 1 17
[OVRManager] OnApplicationFocus(false)
[OVRManager] OnApplicationFocus(true)
[OVRManager] OnApplicationFocus(false)
[OVRManager] OnApplicationFocus(true)
[OVRManager] OnApplicationFocus(false)
[OVRManager] OnApplicationFocus(true)
[OVRManager] OnApplicationFocus(false)
[OVRManager] OnApplicationFocus(true)
[AVProVideo] Shutdown
Disconnecting NS...
[OVRManager] OnApplicationQuit
[XR] Oculus XR Plugin Display Shutdown
Setting up 8 worker threads for Enlighten.
Thread -> id: 62b0 -> priority: 1
Thread -> id: 5fd8 -> priority: 1
Thread -> id: 5ccc -> priority: 1
Thread -> id: 5ee8 -> priority: 1
Thread -> id: 54e0 -> priority: 1
Thread -> id: 5b08 -> priority: 1
Thread -> id: 864 -> priority: 1
Thread -> id: 2920 -> priority: 1
[OVRManager] OnDestroy

You're far from alone. This app has been broken in the same way on my Rift S as well ever since the 13.13 update... The support team has been fairly responsive on my post but still no fix even after the most recent update. Really disappointing that they won't just provide earlier versions to rollback to for those of us who just want to watch our local files the way we've been doing.

One scenario for handling ImageFailed is to set the UriSource of the underlying BitmapImage source to a different local image file. This can serve as a fallback value to display instead of empty space. For example, if you are trying to display an external image where it's possible that the source is no longer there, or for when the user has no Internet connection, you could set the UriSource to reference a local fallback or placeholder image that's part of your app package and is always guaranteed to be available.

For Windows 8, resources can use a resource qualifier pattern to load different resources depending on device-specific scaling. However, resources aren't automatically reloaded if the scaling factor changes while the app is running. In this case apps would have to take care of reloading resources, by handling the DpiChanged event (or the deprecated LogicalDpiChanged event) and using ResourceManager API to manually reload the resource that's appropriate for the new scaling factor. Starting with Windows 8.1, any resource that was originally retrieved for your app is automatically re-evaluated if the scaling factor changes while the app is running. In addition, when that resource is the image source for an Image object, then one of the source-load events (ImageOpened or ImageFailed) is fired as a result of the system's action of requesting the new resource and then applying it to the Image. The scenario where a run-time scale change might happen is if the user moves your app to a different monitor when more than one is available.

If you migrate your app code from Windows 8 to Windows 8.1 you may want to account for this behavior change, because it results in ImageOpened or ImageFailed events that happen at run-time when the scale change is handled, even in cases where the Source is set in XAML. Also, if you did have code that handled DpiChanged/LogicalDpiChanged and reset the resources, you should examine whether that code is still needed given the new Windows 8.1 automatic reload behavior.

Multithreaded applications take advantage of increasing core counts to achieve high performance. Such programs, however, typically require programmers to reason about data shared among multiple threads. Programmers use synchronization mechanisms such as mutual-exclusion locks to ensure correct updates to shared data in the presence of accesses from multiple threads. Unfortunately, these mechanisms serialize thread accesses to the data and limit scalability.

Often, lock-based programs do not scale because of the long block times caused by serialization, as well as the excessive communication overhead to coordinate synchronization. To reduce the impact on scalability, programmers use fine-grained locking, where instead of using a few locks to protect all shared data (coarse granularity), they use many locks to protect data at a finer granularity. This is a complex and error-prone process11,12 that also often impacts single-thread performance.

Transactional memory5 proposed hardware mechanisms to simplify the development of lock-free data structures. They rely on mechanisms other than locks for forward progress and exploit the underlying cache-coherence mechanisms to detect conflict among threads.

Lock elision15 was another proposal to expose concurrency in lock-based programs by executing them in a lockless fast path. It uses the hardware capability of modern processors and the underlying cache-coherence protocol to execute critical sections optimistically, without acquiring a lock. The lock is acquired only when actually required to resolve a data conflict.

In spite of the numerous proposals, high-performance synchronization remains difficult: programmers must use information known in advance to determine when to serialize, and scalable locking is complex, leading to conservative lock placement.

Recently, commercial processors from Intel Corporation and IBM have introduced hardware support to improve synchronization.6,7,9,17 This presents a unique opportunity for software developers to improve scalability of their software.

What is needed is a mechanism that has the usability of coarse-grained locks with the scalability of fine-grained locks. This is exactly what lock elision provides. The programmer must still use locks to protect shared data but can adopt a more coarse-grained approach. The hardware determines dynamically whether threads need to serialize in a critical section and executes the lock-based programs in a lock-free manner, where possible.

The processor executes lock-protected critical sections (called transactional regions) transactionally. Such an execution only reads the lock; it does not acquire or write to it, thus exposing concurrency. Because the lock is elided and the execution optimistic, the hardware buffers any updates and checks for conflicts with other threads. During the execution, the hardware does not make any updates visible to other threads.

c80f0f1006