- Posts: 5
- Joined: Thu Jun 23, 2016 2:46 pm
In order to be notified when USB or Thunderbolt DeckLink/Ultrastudio devices are added or removed from a system, I'm using IDeckLinkDeviceNotificationCallback, as described in the DeckLink SDK documentation, to be informed of device arrival or removal. Device arrival works fine, and my callback object's DeckLinkDeviceArrived() method is called appropriately, but device removal doesn't work, and my callback object's DeckLinkDeviceRemoved() method is never called. Even though DeckLinkDeviceRemoved() isn't called, if I iterate through the DeckLink objects (using IDeckLinkIterator) immediately after device removal, it is clear that the object has been removed, and that's actually how I'm working around the issue, by periodically checking to see if the device has been removed through iteration in the case that I'm dealing with a USB or Thunderbolt device. Plus, the device disappears from Device Manager and Intel's Thunderbolt software device list. Plus, I see a WM_DEVICECHANGE windows message sent to my window when the device is unplugged from the system. So, it would seem that all the information should be available to Blackmagic to detect device removal, and this tends to point to a bug in the Blackmagic software.
This happens on Windows 10 Professional 64-bit on a Intel NUC NUC6i7KYK, on which I'm running the latest BIOS and latest drivers, including the latest Thunderbolt driver from Intel. Since the computer has a Thunderbolt 3 port, I'm using a Startech Thunderbolt 3 to Thunderbolt adapter to connect a Blackmagic UltraStudio Mini Recorder to the system.
On a separate note, there isn't a good way to determine if a particular IDeckLink object is associated with the same underlying hardware device as another IDeckLink object. For example, when I use IDeckLinkIterator to iterate through all the IDeckLink objects, the object pointer associated with the same underlying hardware device typically changes from call to call, as would generally be expected. I tried to use the BMDDeckLinkPersistentID attribute ID as a unique ID, but, at least when it comes to the UltraStudio Mini Recorder, this device doesn't have a persistent ID. The approach that I've settled upon is to use IDeckLink::GetModelName()--if the model names returned are the same, then I interpret this to mean that I'm dealing with the same underlying hardware device. But, I don't think that this approach is guaranteed to produce uniqueness, and it would be preferable if a better approach were available. I also tried using the undocumented BMDDeckLinkDeviceHandle, which supposedly returns a string, but the software crashed in DeckLink code when I attempted to use it, and I believe that I passed in correct arguments.
This happens on Windows 10 Professional 64-bit on a Intel NUC NUC6i7KYK, on which I'm running the latest BIOS and latest drivers, including the latest Thunderbolt driver from Intel. Since the computer has a Thunderbolt 3 port, I'm using a Startech Thunderbolt 3 to Thunderbolt adapter to connect a Blackmagic UltraStudio Mini Recorder to the system.
On a separate note, there isn't a good way to determine if a particular IDeckLink object is associated with the same underlying hardware device as another IDeckLink object. For example, when I use IDeckLinkIterator to iterate through all the IDeckLink objects, the object pointer associated with the same underlying hardware device typically changes from call to call, as would generally be expected. I tried to use the BMDDeckLinkPersistentID attribute ID as a unique ID, but, at least when it comes to the UltraStudio Mini Recorder, this device doesn't have a persistent ID. The approach that I've settled upon is to use IDeckLink::GetModelName()--if the model names returned are the same, then I interpret this to mean that I'm dealing with the same underlying hardware device. But, I don't think that this approach is guaranteed to produce uniqueness, and it would be preferable if a better approach were available. I also tried using the undocumented BMDDeckLinkDeviceHandle, which supposedly returns a string, but the software crashed in DeckLink code when I attempted to use it, and I believe that I passed in correct arguments.