Olympus-OM
[Top] [All Lists]

Re: [OM] Pervasive Windows file system bug and E-M5 date/time failure

Subject: Re: [OM] Pervasive Windows file system bug and E-M5 date/time failure
From: Jim Nichols <jhnichols@xxxxxxxxxxxxx>
Date: Sat, 02 Nov 2013 20:38:36 -0500
It is just a matter of work habits.  I make it a habit to turn off the 
power and unplug the USB cable BEFORE doing any photo processing.  It 
helps that I put my camera back in its bag after each session, checking 
once again that the power switch is OFF.

Jim Nichols
Tullahoma, TN USA

On 11/2/2013 8:21 PM, Chuck Norcutt wrote:
> I'm not really your compatriot here.  I wouldn't normally use a USB
> cable from camera to computer since the camera is only spec'd at USB
> 2.0.  My computer has USB 3.0 ports and will download faster if the the
> card is removed from the computer and hooked into a reader using the USB
> 3.0 port.  But my ebay handgrip (which I dearly love) has the bad habit
> of covering the card socket.  The card can't be removed without a
> screwdriver to remove the hand grip.  If I had many hundreds of images
> to download I'd remove the grip so I could download faster.  If its just
> a few images (in this case it was 17x2 (ORF plus JPEG) I'll just connect
> the camera.  But that can also be a pain as I have twice forgotten to
> disconnect and power off the camera until the following day or longer
> and that's what led to the loss of date/time.
>
> Chuck Norcutt
>
> On 11/2/2013 9:03 PM, Jim Nichols wrote:
>> Glad you figured it out, Chuck.
>>
>> The most interesting part of your story was your admission that,
>> contrary to all of the folk lore, you download images using a USB
>> cable.  I have done this ever since I got my first digicam, and have
>> never had a problem.  But, all of the "old timers" seem to treat this as
>> heresy.  Glad I found a compatriot! :-)
>>
>> Jim Nichols
>> Tullahoma, TN USA
>>
>> On 11/2/2013 7:51 PM, Chuck Norcutt wrote:
>>> Yesterday I went out to capture some late fall golden sunlight with the
>>> E-M5.  Unfortunately, the wind was blowing about 30 mph but I thought
>>> maybe I could capture some "artistic" blurred images.  Unknown to me
>>> that was the beginning of a strange adventure.
>>>
>>> As soon as I got outside and turned on the camera I saw a strange (and
>>> undocumented) error display screen from the camera... a large, analog
>>> clock face with something like Year/Month/Day displayed in orange on a
>>> black background.  It was a surprise.  After thinking about it for a
>>> moment I realized that it must be a warning message that the date and
>>> time were not set.  But it didn't bother me that the date and time might
>>> not be correct.  I was going to grab a handful of images and be done
>>> with it.  The sun was going down, the light was changing rapidly and I
>>> wanted to take pictures, not fiddle with the camera's clock.  Bad
>>> decision.
>>>
>>> But first, how did it happen?  I tend to forget that the camera is on if
>>> I have it connected to a USB port to download images.  I remembered that
>>> I had twice run the battery to exhaustion recently.  I had thought
>>> nothing of it at the time and had merely recharged the battery.  The
>>> first time it happened there were no other repercussions.  But this time
>>> was different because the date and time were lost.  The E-M5 manual
>>> says: "The date and time settings will be returned to the factory
>>> default settings if the camera is left without the battery for
>>> approximately 1 day. The settings will be cancelled more quickly if the
>>> battery was only loaded in the camera for a short time before being
>>> removed. Before taking important pictures, check that the date and time
>>> settings are correct."
>>>
>>> It would appear from the second sentence above that the date/time
>>> settings are maintained by some sort of capacitor rather than a separate
>>> battery.  Therefore, if the battery has only been in a short time the
>>> capacitor may not be fully charged and the date/time may be lost in less
>>> than a day.  But the fact that the date/time would be set to factory
>>> defaults didn't bother me.  I didn't care what the date and time might
>>> be.  Maybe the announce date of the E-M5.  Maybe 00:00:00.  Maybe
>>> Maitani's birthday.  I didn't care.  But I should have and you should
>>> too.  Here's why.
>>>
>>> When I started shooting there were already about 100 images on the card
>>> which had previously been downloaded.  The last image number ended in
>>> 335.  I shot 17 images and then tried to download using my Win7 system
>>> and a download application.  When it listed the files on the card the
>>> only things that appeared in the list were the images that had already
>>> been there... the last image was 335.  It was as though the new images
>>> didn't exist.  I scratched my head for a few seconds, disconnected the
>>> camera from the computer and started reviewing images on the camera's
>>> display screen.  There were the missing images but with nothing
>>> displayed where the date and time should be.  It was as though the data
>>> were ASCII blanks and not numerics.  I reconnected the camera and used a
>>> Windows file utility directly on the flash card without any intervening
>>> application software.  Same result... the files didn't exist.  I tried a
>>> freebie Windows file recovery utility.  Same result again.  The files
>>> didn't exist unless I told the utility to ignore the directory and go
>>> for low level data.  That got the files with 0000:00:00 00:00:00 for
>>> date/time stamps but with file names generated by the utility.  Better
>>> than nothing but not ideal.
>>>
>>> Finally, I tried Ubuntu Linux.  Ubuntu did much better since it saw and
>>> recovered all the proper file names and also substituted 0000:00:00
>>> 00:00:00 for the apparently blank time stamps.  But even it was
>>> mysteriously confused.  At first I didn't think it had worked since I
>>> didn't see the files listed.  I had expected them at the end of the
>>> list.  In fact, they were at the beginning of the list.  I then assumed
>>> that the list was sorted by date/time and all the 0s were forcing the
>>> previously missing files to the top of the list.  I then forced a sort
>>> by file name... or so I thought.  Rather than sort to the bottom of the
>>> list where they should have been they continued to maintain their
>>> position at the top.  I still haven't figured that one out.  I gave up
>>> pondering that development and decided to be happy that I had my files
>>> back with proper alpha-numeric names with numbers running from 336 to 352.
>>>
>>> Moral of the story:  When you see the orange clock face warning message
>>> you should immediately reset the date/time.  Maybe Apple utilities are
>>> smarter but I was surprised that even Ubuntu Linux didn't get it
>>> completely right.  And I was especially surprised that this simple bug
>>> has apparently persisted in Windows at least throughout the lifetimes of
>>> WinXP and Win7 and likely much longer.  Makes me wonder too what Oly
>>> used for testing.  Probably hired the US HealthCare.gov web developers. :-)
>>>
>>> Chuck Norcutt (all mentally tuckered out)
>>


-- 
_________________________________________________________________
Options: http://lists.thomasclausen.net/mailman/listinfo/olympus
Archives: http://lists.thomasclausen.net/mailman/private/olympus/
Themed Olympus Photo Exhibition: http://www.tope.nl/

<Prev in Thread] Current Thread [Next in Thread>
Sponsored by Tako
Impressum | Datenschutz