Check this technote for possible solution:

Article URL http://www.symantec.com/docs/TECH62822

<deleted>

Did you use NBU to eject tapes from RobotA before putting into RobotB?

If not, just select tapes, right-click, Move, and choose Standalone.

Next, inventory RobotB.
This should move tapes from standalone to new location.

I know the tape is not unique it's coming from another robot, but from the same media server.

Does that mean you have 2 tapes witht the same BARCODE?

or is it just the issue that Marianne mentioned that you did not eject it correctly from the other robot?

You CANNOT have 2 tapes with the same BARCODE within the same MASTER/NB domain.

I get the same message in one of our NB domain. We get the error when we swap the tapes between the robotic library, and one of our barcode scanner has limitation, where it can read only first 6 characters (RobotA) and other scanner can read all 8 characters (RobotB).

Media Barcode: NB1234L4

Media ID Generation: 1:2:3:4:5:6 (for both robots)

On inventorying RobotA:

                                   Barcode: NB1234

                                   Media ID: NB1234

Now, i eject the tape and insert in RobotB:

                                   Barcode: NB1234L4

                                   Media ID: NB1234

When we swap the tapes between the robots, the barcode detected is different, but the Media ID (NB1234) is already present (not unique) in the Volume DB and hence the error message "media ID not unique in database (34)". This is the behaviour of NetBackup, so to overcome; instead of deleting, we use VMCHANGE command to change the media barcode prior inventorying the tapes which we swap.

Hope this helps you!

Bonjour all of you,

I do not have 2 tapes with the same BARCODE.

I will look into Mrs.van den Berg solution.

The problem it's a remote site and I do not use the CAP for ejection.

I just take off the whole drawers of my HP MSL6030 and my HP MSL6060.

One thing I did not said is, those tapes are a come back from Iron Mountain.

I do not take the tapes and switch them over from a library to another.

It's a tape with an image that expired and came back from Iron Mountain...

Thanks for you answers.

NBU Admin guide I also explains that when media is moved between robots, the media should first be moved to Standalone as intermediate step.
Inventory cannot do it in one step.

Bonjour,

I feel there is no solution.

Moving or deleting every tapes to switch them between robots is not very practical or convenient or fast.

Thanks

what is the meaning of "Bonjour" 

Maybe create a script that will deletes all the tapes that are in scratch pool.

But if I do I will not know what tapes to recall from Iron Mountain...

OK, if you know which tapes to recall, you can "move" those media per Marianne's suggestion.  They do not have to be physically in the library to do that logical "move". 

Did you verify library settings per my original post? 

If the Media ID is not Unique in Library. It is already having entry of the media in the Tape Library.

Remove the dummy entry with below command and do the inventory again.

1. Delete the volume DB entry
<install_path>\Program Files\Veritas\Volmgr\bin\vmdelete -m 000AA6.

OK - let us try to understand....

Tapes are ejected/removed from Robot1 and Robot2 = Standalone?

Returned from offsite and inserted into robot - not always back in same robot, right?

If tapes that were previously in Robot1 are now inserted in Robot2 (or vice versa) you see this error?

Question:
how does Robot1 read tape labels?
how does Robot2 read tape labels?

If the two robots read and report labels differently, you will see this error.

Please do the following from cmd from both robots and show us output: This command is equivalent of 'Compare contents' in Inventory. (there are really 3 x's in command).

vmcheckxxx -rt <robot-type> -rn <robot-number> -rh <robot-host>

(command is in volmgr/bin)

I reckon we might be back at Bill;s first reply above: https://www-secure.symantec.com/connect/forums/med...

as well as Rizwan's post: https://www-secure.symantec.com/connect/forums/med...

vmcheckxxx output will confirm!

Bonjour all,

Thing are going bad here as we lost our library.

Marianne you are right about the situation

Honnestly I will look deeper in Bill's solution with the replacement library.

I will post next week, when the library has been replaced.

The broken library is out of warranty and the robot inside it is broken.

Stay tuned folks ;-)