This problem first appeared in B&R 8x, with the change to remote tape providers vs accessing tape devices directly connected to the server running B&R in version 7x. Even when the "remote" tape server is in actuality the local server that is running B&R as well as the management console, automatic polling of the status of standalone tape devices is entirely nonfunctional. You have to manually initiate an inventory operation on the drive in question in order for it to update its status(eg: whether it is loaded or not, and which tape is present if any, as well as updating the online/offline status of said tape if it happens to be cataloged). This is a version-killer for large file-to-tape backup jobs, where you are manually changing tapes throughout the job run, which may take up to 10 tape changes in some instances. With the new tape communication topology introduced in version 8 and onwards, you have to manually perform an inventory operation on the drive every time you insert a new tape in order for it to be detected by the software, regardless of if you do so when instructed by a running backup job after it ejects the full tape, or if the system is merely idle and you have manually loaded a tape, or if you simply pressed the physical eject button on the drive. Furthermore, the inventory task itself takes over 70 seconds to correctly identify a drive as empty if ran when the drive is as such for some unknown reason, whereas it only takes roughly 25 seconds to identify a loaded cartridge.
I originally rolled back to B&R 7x to avoid this issue, however I have recently upgraded my host to esxi 6x, which is unsupported by B&R 7x. As a result I had to upgrade to version 9.5, only to find that all the problems I experienced with the 8x branch are still present. Obviously I could run two separate guests, with different versions of B&R on each, and then attach them to the same storage repository(I'm using SMB as my transport, as is the only option for communication with a freenas machine(or VM in my case), so it would technically be possible to have two separate versions of B&R attached to the same repository, since the veeam network transport provider isn't being used in this configuration), using one machine to interface with esxi 6x and push veeamzip files of my VMs onto the repo and the second machine to dump them to tape, but that is such a hideous kludge for something that should work correctly in the first place, that I don't even want to think about what could go wrong with a setup such as that...
My setup is esxi 6x, on a free license, guest OS for veeam is server 2008 r2 with B&R 9.5(also on a free license), and the tape drive(an HP Ultrium 1840 full height internal(LTO4)) is passed to the guest by using vt-d on the SCSI HBA that it is connected to(seeing as how vmware "blacklisted" the passthrough of SCSI tape devices via the native SCSI passthrough feature, this is my only option other than building an entire separate physical server and using iSCSI(out of the question)). While it might seem to be a "janky" setup, I've thoroughly tested this vt-d based configuration under esxi 5.5 and B&R 7x, and it has functioned flawlessly for two years now. It was only when I upgraded my esxi installation to the 6x branch and thus needed to update B&R as well that the issues with the tape drive status polling appeared once more.
The documentation says that after a remote tape provider is configured "Afterward, the auto-discovery process will be performed periodically every 3 minutes." I've let it idle for 30+ minutes after inserting a cataloged cartridge, and the drive still reports its status as empty until I manually inventory it(as I stated earlier, under the old tape topology in B&R 7x, the tape drives status would be updated automatically whenever it was loaded or unloaded, and update nearly instantly at that).
Is there any solution out there for this? Or is my only option really to roll back to B&R 7x for proper tape support. Any assistance with this matter would be greatly appreciated.