Funston: b0673 ops to rrw 06/03/2011

[microfilm-ops]

Scanning Center: Funston
Description of failure: derive.php - redrow
http://www.archive.org/catalog.php?history=1&identifier=soundex1910ms107

[Hank Bromley (hank-archive)]

I emailed Paul, Jesse, and Dan about this item when it happened - two scans were uploaded nearly simultaneously for the same item from two different processing machines, and it now has mis-matching scandata and original jp2s.

Also, I see the item has been marked "approved" - how does that happen when it doesn't have *any* derived formats?

Date: Mon, 25 Apr 2011 12:22:32 -0400 (EDT)
From: Hank Bromley
To: Paul Nguyen, Jesse Bell
Cc: Dan Hitt
Subject: Re: ufilm collision

The item is going to need some cleaning up. The second set of images
ended up replacing a set of processed jp2s with a set of original jp2s,
and the derive failed (well, both derives failed, one for each copy) when
it tried to process the original jp2s with mis-matching scandata.

-- Hank

On Mon, 25 Apr 2011, Hank Bromley wrote:

> How did this happen?
>
> http://www.us.archive.org/catalog.php?history=1&identifier=soundex1910ms107
>
> Two image uploads, submitted 18 seconds apart from two different ufilm
> processing machines:
>
> 2011-04-25 15:00:02 75587406 (from 06p)
> 2011-04-25 14:59:44 75587380 (from 07p)
>
> I've already written Paul and Jesse about the two scans for the same ID; what
> I'm wondering now is why the first upload didn't block the second - shouldn't
> the item have been read as "busy" at that point?
>
> -- Hank

[microfilm-ops (microfilm-ops)]

Thank you for the information, Hank,

my question:
- what can we do as far as 'cleaning up' to get this item online?

Also, as far as the item being 'approved' without derived formats: I am looking into this.

[Hank Bromley (hank-archive)]

Well, you should consult with Paul about this item, but we can't use the current images with the current scandata. And given that the current images are designated "orig jp2s," we also can't use them without any scandata at all. So I see two options:

- Rename the current image stack to be "processed jp2s" (i.e., unpack the tar, take the "orig" out of the names of all the individual image files and the directory they're inside, then repack into either a zip or tar), replace the existing orig jp2 tar with the new processed jp2 zip/tar, and delete the scandata. Then when we derive it, we'll automatically make a minimal scandata.xml that matches the images.

- Gut the item and rescan.