I'm using the 3-hole label template.
Amanda version is 2.5.0p2 from zmanda on Fedora 4.

I'm taping to vtapes and tape spanning is turned on.
Though I seldom exceed one tape the dumps are still
split into tape_splitsize chunks.

It appears to me that the "File #" column in the report
is meaningless, except for the ordering of the dumps on
the tape.  The numbers simply increase by 2 for each DLE.
So File #0 is the tape header, #2 is the first DLE dump,
#4 is the second DLE etc.  It doesn't matter if the DLE
took 1 split or 50, the next File # is increased by 2.

On physical tapes I would have expected these File #'s
to allow me to "mt fsf" to that # and extract the dump
I wanted.  Clearly that is not the case for my reports.

To confirm this I used ammt rewind and ammt fsf to advance
to several file numbers.  When I used amdd to read the
vtape header it matched the 5 digit file numbers on disk
rather than the "File #" from the printed report.

Is it my misunderstanding of the report's File # or some
problem generating the numbers?

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)