I can understand this:
the robotic arm has no way of knowing about the NDMP drive because it is using a Windows driver to control it. The library is aware of the drive but Windows will not use it. It does, however, know which tape the restore data is on, so it will search for it on that drive that's connected local to the media server, even though the data is located on the other.
However, in some parts, BE is smarter. BE does know that the drive exists (it shows under devices under the library) and it does know it is controlled by NDMP (the first drive shows "controlled by: Kernel device driver", the second shows "controlled by: NDMP").
Further, I also tried the following: I deleted a tape from the media catalog (dragging it to the retired media set, then deleting it) without physically erasing the tape, so the catalog information in BE is deleted for that tape. Then I attemted an Inventory followd by a Catalog action. The inventory was executed in the first drive (reading the tape header) but the catalog job was executed in the second (NDMP) drive! The catalog job was succesfull and I again had access to the detailed contents of the tape.
Also, if I specify which drive to use in a restore job, I expect it to use that drive. BE just did not use that drive (as described in my original posting). It seems BE just tried the restore in the first available drive, which happened to be drive no. 1. After pausing drive 1, the first available drive was drive 2, so then the restore was succesfull.
So... if the design is to use a local tape drive controlled by the media server for restores, then why does it use a drive controlled by NDMP for a catalog job of an NDMP tape?
Hope you can shine some light on this.
Anton