SDK6.4 C# WPF .NET45 - IBMDSwitcherStillsCallback problems

I've been working with the Switcher SDK 6.4 for about a week now. My test application is written in C# using VisualStudio 2013, .NET 4.5, and WPF. I've been very successful enumerating inputs, and performing transitions with my ATEM TelevisionStudio, but I am having one bizarre problem.

When I try to upload a 'still' (SwitcherFrame) to the switcher, I execute a Lock, receive the Lock callback, add a callback to the SwitcherStills, and tell the stills to upload my SwitcherFrame. This all works fine except I never receive a _BMDSwitcherMediaPoolEventType.bmdSwitcherMediaPoolEventTypeTransferCompleted event when the upload is complete.

I have spent days trying to figure out why? When I use (almost) identical code in a windows console application I receive this event notification perfectly. But as soon as I try the code under WPF, the event is never received. The only difference between these two test apps is the WPF code must Disptach the event callbacks to the UI thread to keep COM happy under the hood. When I remove the Dispatcher.Invoke logic from my WPF app, the callbacks occur on a different thread and I can no longer reference some COM objects without getting 'Unable to Query Interface' errors, so I think it is appropriate to handle the callbacks on the UI thread. (I've read that COM behaves best when used from an STAThread, and I think the UI thread for windows apps is STA anyway).

I do manage to get other notifications, including (when appropriate):

_BMDSwitcherMediaPoolEventType.bmdSwitcherMediaPoolEventTypeLockBusy
_BMDSwitcherMediaPoolEventType.bmdSwitcherMediaPoolEventTypeNameChanged
_BMDSwitcherMediaPoolEventType.bmdSwitcherMediaPoolEventTypeHashChanged

but for the life of me, I can not get

_BMDSwitcherMediaPoolEventType.bmdSwitcherMediaPoolEventTypeTransferCompleted

Does anyone have any advice for me? I'll take any ideas at this point. I'm totally stumped.

Just wanted to add some additional details to my original post.

I tried downloading a SwitcherFrame from the Stills and confirmed I DO get the completed event type in the callback. It's only the Upload that stubbornly refuses to raise the event.

I'm still looking for any suggestions!

I've been over my code a few hundred times now, and I am pretty certain that whatever is going on it is outside of my control. I suspect it's a bug or incompatibility between the Blackmagic COM control and WPF.

I simply can not get a TransferCompleted event when uploading to the switcher. I decided to work around the issue by Invalidating the still before uploading, then I can watch the events that I do receive to figure out when the upload it complete (generally, HashChanged, ValidChanged, and NameChanged).

The problem however is that while this works to notify my code that the callbacks can be released and the stills unlocked, when I issue my second upload I start getting errors (within the IDE) like this:

InvalidCastException

Unable to cast COM object of type 'System.__ComObject' to interface type 'BMDSwitcherAPI.IBMDSwitcherFrame'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{35A1F6A6-D317-4F89-A565-0F0BD414CF77}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).

If I ignore the exception, and press forward, I will eventually get the following exception:

FailedQI was detected

The call to QI for interface 'BMDSwitcherAPI.IBMDSwitcherFrame' with IID '{35A1F6A6-D317-4F89-A565-0F0BD414CF77}' failed with HRESULT 0x80004002 (No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE))). One likely reason this failed is that the object does not have a proxy/stub dll properly registered.

Again, if I ignore the exception and press forward everything simply stops working... Obviously thats not acceptable for a shipping product. So I am stuck. I can easily wrap an example project in C# that clearly demonstrates this behavior (I have replicated the behavior across multiple environments). Is there a way to contact support and have them attempt to replicate the problem?

[Matt Jefferson]

Yes, you can use the website support page after you select the product type and scroll down to middle lower section which has the support form for general. Alternate is to use the SDK support email that is listed in the SDK manual. It is bottom of page 27 of the ATEM SDK manual. Due to spam, I do not post it on the forum.

Matt Jefferson

Matt, thanks for the info.

For anyone that is interested; I was able to determine the following. First, I must admit a problem in my 'work around code' that was causing my application to seemingly 'hang'. In an effort to work around the missing TransferComplete message, I wrote a method to keep track of received messages and 'figure out' when the upload was complete (based on HashChanged, NameChanged, and ValidChanged). However, I failed to take into account the messages I receive are different when replacing a still versus uploading a still into a new (empty) slot. So I was hanging in my own code when uploading to an empty slot. Whoops. My bad.

The exceptions I reported appear to have no impact on my runtime. Now that I'm not getting 'stuck' anymore, I compiled an exe and ran a few thousand iterations of uploading/downloading stills to the ATEM without problem. That currently satisfies me regarding predictability and stability. (Interestingly, I also seem to only get these COM exceptions under Windows 7). I might do some memory profiling going forward...

So my only remaining mystery is my original question, which is why I never receive the TransferComplete message (or TransferCancelled or TransferFailled) when uploading a still. I am going to wrap a short example in C# to provide to Blackmagic's developers and see what they make of it. When/If I know the answer, I'll post it to my thread here in case it is helpful to anyone else.

Hi Folks

I'd like to add that I'm having exactly the same problem with C# Windows Forms. The TransferComplete message (or TransferCancelled or TransferFailled) are never received.

Do you have any update George from support?

And thanks for the work around tip - got it working nicely. Still it would be better to have it working as intended.

[Nicholas Gill]

Hi George / Joel,

Is it possible to provide a minimal sample which reproduces this issue?

You could provide that to the developer support address (bottom of page 27 of the ATEM SDK manual) and I can take a look.

Cheers,

-nick

Hi Nick

Thanks for following this up.
Have sent an email with demo project as requested.

Regards

Joel

[Nicholas Gill]

Hi Joel,

Thanks for the C# sample application provided via email.

The core of the issue is that the bmdSwitcherMediaPoolEventTypeTransferCompleted, TransferCancelled, and TransferFailed events are fired in a different thread context to the other events.

The C# sample as provided is using a Single Threaded Apartment [1].

Changing the [STAThread] attribute on Main() in Program.cs to [MTAThread] allows the COM layer to callback into the application, and the events are received as expected.

Cheers,

-nick

[1] https://msdn.microsoft.com/en-us/library/ms809971.aspx

I just want to add this into the mix. It is my understanding that WPF *requires* the application to be run using an STAThread. This would seem to be at odds with the requirement of using an MTAThread to receive callbacks/events from COM.

[Nicholas Gill]

Hi George,

The MTAThread attribute does not need to be applied to the Main thread / UI thread, this was just the example used in reference to the SwitcherPanelCSharp SDK example.

The C# thread which is interacting with the Switcher SDK must have the MTAThread attribute, this page [1] shows how the MTAThread attribute can be applied to a new thread.

Cheers,

-nick

[1] http://blogs.msdn.com/b/jfoscoding/arch ... 06341.aspx

Hi Nick

Thanks for looking at this and for explaining the issue.

Joel