Chuck Norcutt wrote:
> I also have a hard time believing that that camera can't see what it was
> displaying only minutes ago. The scenario doesn't seem to make much
> sense. The directory would have to be damaged some time between viewing
> the last image on the camera and removing the card.
>
- The sketchy report indicates that more than one different card was
involved, so the chances of hardware failure there are extremely low.
- Use of the "preview" feature is mentioned. What isn't mentioned is
whether this is literal or a mis-statement. "Preview" is the display of
the image immediately after it is taken and need not necessarily
indicate that the image is on the card. It may be, probably is, from the
buffer. "Review" is going back to a previous image. Review must read the
image from the card, thus indicating that it was successfully written.
It is thus, from a diagnostic point of view, much different than preview.
- If review was indeed tried before ejecting the card and could not
retrieve images after putting it back in, something has indeed happened
in between.
- The logical way to troubleshoot is NOT to go ahead and do another
client shoot.
1. Take a few test images, review them in camera.
2. Remove and replace the card in the camera and try review again. Write
down at least one file name.
3. Remove card and put it in the card reader.
4. Use the system file viewer, Windoze Explorer or Mac Finder, to view
the contents of the card as file names.
5. Use whatever software was being used to view/copy files. Before doing
the copy:
a. Check the settings for output directory against expectations of
where the files should appear.
b. Check settings to see if source files are to be erased from the
card once copied.
6. Do a system wide search for one of the file names.
- That should isolate where the files are "going missing", leading to a
similar process to isolate hardware, software or user error at the step
where they disappear. Several good suggestions have already been made,
but logical testing is the only way to isolate the problem for sure.
------------------------------
I have, as M. Vick wishes were true of other fights, no dog in this
fight. I have, however done a bit of remote troubleshooting of computer
issues and specifically of them as related to software I wrote.
My general rule, learned from hard experience, when something that works
everywhere else, but not in one particular location and/or with one
particular person, is that it is caused by an unstated action or
assumption. Usually something that is happening/being done, but not
reported.
Over several programs and many years and incidents, I never found a
problem with a unique user that was in my software. I don't think I
recall any hardware failure either. Mostly operator error, occasional
LAN admin errors and one bug in a major LAN OS that they eventually
admitted to, but never fixed. I had to recode around that one.
People NEVER tell you the whole, blow-by-blow story unless you force
them to walk through it one detail step at a time. Typical is walking
through the process on the phone, hearing keystrokes when I've not said
the next thing to do, asking what they are doing and hearing "Oh, just
such and so. I always do that, so I didn't want to bother you with it."
or some such nonsense. And that will turn out to be where the problem
is. It's quite remarkable how we can make a change in some detail of a
process without noticing it, then go on doing it the new way.
Unstated assumptions are the killer. As I recently noted and old timers
will remember, there was the case here of the "bad" lens where the
owner/complainer never thought to mention it had a 'protective" filter
always mounted and it took months before anybody thought to ask.
----------------------
Moose
==============================================
List usage info: http://www.zuikoholic.com
List nannies: olympusadmin@xxxxxxxxxx
==============================================
|