[PhotoFloat] python ValueError: time data '0000:00:00 00:00:00' does not match format '%Y:%m:%d %H:%M:%S

Tom Talpey tom at talpey.com
Tue Dec 16 22:17:40 CET 2014


On 12/16/2014 3:08 PM, Dennis Ortsen wrote:
> Well, it was just a matter of time before I’d run into another image with faulty exif dates :-)
>
> I applied your patch and re-ran the scanner and voila! It finished without problems!
>
> Again: thank you very much!

Glad to hear it. The patch is kind of a hack as I said, basically
your unmarked pictures are now marked as taken in 1/1/1900, which
is basically what the original code was doing, but the patch doesn't
bomb out. It seems (to me) that it could try harder to find a more
reasonable date, but I only had a few photos with the issue, so it
wasn't worth spending time on.

>
>
> Op 15 dec. 2014, om 23:39 heeft Dennis Ortsen <dortsen at gmail.com> het volgende geschreven:
>
>> I’ve added more images, to find out they had the same issue, from that same camera. I already fixed those images with correct exif information. But looking at your code (I’m not a python expert) a try/catch would indeed stop the scanner from bailing out. I’m running the scanner at this moment and will certainly apply your patch at the next moment a faulty exif is encountered!
>>
>> Thanks!
>>
>>
>> Op 15 dec. 2014, om 22:57 heeft Tom Talpey <tom at talpey.com> het volgende geschreven:
>>
>>> On 12/15/2014 4:43 PM, Dennis Ortsen wrote:
>>>> To answer Tom’s reply
>>>>
>>>>> The latest git has a fix for this, btw. When there is no date-taken
>>>>> tag, it falls back to using the timestamp of the jpg. I don't think
>>>>> the distros have picked this up.
>>>>>
>>>>> This doesn't really have anything to do with auth (subject of thread).
>>>>
>>>> I’ve cloned the git repo on december 11 (as outlined on
>>>> http://git.zx2c4.com/PhotoFloat/about/). I see that the last commit on
>>>> august 25 this year was meant to fix this. But it’s exactly this piece
>>>> of code that python chokes on…
>>>
>>> Oh, in fact I had the same issue, and hacked up this patch.
>>> Maybe it will work for you?
>>>
>>> diff --git a/scanner/PhotoAlbum.py b/scanner/PhotoAlbum.py
>>> index fffe4ac..08a463f 100644
>>> --- a/scanner/PhotoAlbum.py
>>> +++ b/scanner/PhotoAlbum.py
>>> @@ -309,14 +309,19 @@ class Photo(object):
>>> 		correct_date = None;
>>> 		if not self.is_valid:
>>> 			correct_date = datetime(1900, 1, 1)
>>> -		if "dateTimeOriginal" in self._attributes:
>>> +		elif "dateTimeOriginal" in self._attributes:
>>> 			correct_date = self._attributes["dateTimeOriginal"]
>>> 		elif "dateTime" in self._attributes:
>>> 			correct_date = self._attributes["dateTime"]
>>> 		else:
>>> 			correct_date = self._attributes["dateTimeFile"]
>>> 		if isinstance(correct_date, unicode):
>>> -			correct_date = datetime.strptime(correct_date, '%Y:%m:%d %H:%M:%S')
>>> +			try:
>>> +				correct_date = datetime.strptime(correct_date, '%Y:%m:%d %H:%M:%S')
>>> +			except KeyboardInterrupt:
>>> +				raise
>>> +			except:
>>> +				correct_date = datetime(1900, 1, 1)
>>> 		return correct_date
>>>
>>> 	def __cmp__(self, other):
>>>
>>>
>>>
>>>>
>>>> Br.
>>>>
>>>> Dennis
>>>>
>>>>
>>>>
>>>>
>>>> Op 15 dec. 2014, om 22:37 heeft Dennis Ortsen <dortsen at gmail.com
>>>> <mailto:dortsen at gmail.com>> het volgende geschreven:
>>>>
>>>>> I’m starting a new thread on this topic since Tom Talpey made me aware
>>>>> of continuing a thread which had nothing to do with the subject.
>>>>> (Thanks Tom)
>>>>>
>>>>> OK, this is what I mentioned to keep things clear and usable:
>>>>>
>>>>> first mail message:
>>>>>
>>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> Sadly I’ve run into an error, I’m not that much into python, perhaps
>>>>> someone has encountered this before and can pinpoint me?
>>>>>
>>>>> I’m running an updated Ubuntu 14.04.1 and a git clone of PhotoFloat
>>>>> from this week. When running the scanner’s main.py, somewhere along
>>>>> the process an image is found with a different date/time format:
>>>>>
>>>>> 2014-12-11T23:11:48.670837   |  |--[thumbing]      IMG_3092.JPG -> 800px
>>>>> 2014-12-11T23:11:49.343290   |  |--[thumbing]      IMG_3092.JPG -> 1024px
>>>>> 2014-12-11T23:11:50.295564   |--[caching]       Liza
>>>>> Traceback (most recent call last):
>>>>> File "./main.py", line 23, in <module>
>>>>>    main()
>>>>> File "./main.py", line 17, in main
>>>>>    TreeWalker(sys.argv[1], sys.argv[2])
>>>>> File "/var/www/photofloat/scanner/TreeWalker.py", line 16, in __init__
>>>>>    self.walk(self.album_path)
>>>>> File "/var/www/photofloat/scanner/TreeWalker.py", line 55, in walk
>>>>>    album.add_album(self.walk(entry))
>>>>> File "/var/www/photofloat/scanner/TreeWalker.py", line 76, in walk
>>>>>    album.cache(self.cache_path)
>>>>> File "/var/www/photofloat/scanner/PhotoAlbum.py", line 68, in cache
>>>>>    self._sort()
>>>>> File "/var/www/photofloat/scanner/PhotoAlbum.py", line 51, in _sort
>>>>>    self._photos.sort()
>>>>> File "/var/www/photofloat/scanner/PhotoAlbum.py", line 323, in __cmp__
>>>>>    date_compare = cmp(self.date, other.date)
>>>>> File "/var/www/photofloat/scanner/PhotoAlbum.py", line 319, in date
>>>>>    correct_date = datetime.strptime(correct_date, '%Y:%m:%d %H:%M:%S')
>>>>> File "/usr/lib/python2.7/_strptime.py", line 325, in _strptime
>>>>>    (data_string, format))
>>>>> ValueError: time data '0000:00:00 00:00:00' does not match format
>>>>> '%Y:%m:%d %H:%M:%S'
>>>>>
>>>>> How can I find out which file(s) the scanner is choking on? Or perhaps
>>>>> someone can tell me in which order the scanner processes file
>>>>> (alphabetically, order by oldest or first folder/file)?
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> For what it’s worth: I’ve added a second ip address to my ubuntu for
>>>>> ease of Nginx configuration and thus it’s not accessible from the
>>>>> Internet (I’ve port forwarded http and https on a different ip address).
>>>>>
>>>>> ++++++++++++++++++++++++++++++++++++++++++++
>>>>>
>>>>> Later I replied to the above with this message:
>>>>>
>>>>>
>>>>> +++++++++++++++++++++++++++++++++++++++++++++
>>>>> Should anyone encounter this in the future, I corrected the exif
>>>>> information in the affected images (which was wrong anyway) using
>>>>> exiftool.
>>>>>
>>>>> (helpful links:
>>>>> http://dimitar.me/change-the-date-and-time-or-any-other-exif-image-meta-data-of-pictures-with-ubuntu/ and
>>>>> https://fitzcarraldoblog.wordpress.com/2011/08/17/exiftool-comes-to-the-rescue-when-i-need-to-fix-the-date-and-time-in-a-batch-of-photo-files/)
>>>>>
>>>>> It turned out that certain images taken by a certain camera a few
>>>>> years ago had a correct file creation time, but the Date/Time
>>>>> Original fields were indeed set to all zeros.
>>>>>
>>>>> I’m not a programmer, If I could, I’d like to help to include a check
>>>>> when scanning the images that if such exif information was found, the
>>>>> scanner would report them (on the running screen for instance, perhaps
>>>>> a summary at the end) and skip the failing images.
>>>>>
>>>>> +++++++++++++++++++++++++++++++++++++++++++++
>>>>>
>>>>>
>>>>> And Tom Talpey answered the following on that:
>>>>>
>>>>> +++++++++++++++++++++++++++++++++++++++++++++
>>>>> The latest git has a fix for this, btw. When there is no date-taken
>>>>> tag, it falls back to using the timestamp of the jpg. I don't think
>>>>> the distros have picked this up.
>>>>>
>>>>> This doesn't really have anything to do with auth (subject of thread).
>>>>> +++++++++++++++++++++++++++++++++++++++++++++
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> PhotoFloat mailing list
>>>> PhotoFloat at lists.zx2c4.com
>>>> http://lists.zx2c4.com/mailman/listinfo/photofloat
>>>>
>>> _______________________________________________
>>> PhotoFloat mailing list
>>> PhotoFloat at lists.zx2c4.com
>>> http://lists.zx2c4.com/mailman/listinfo/photofloat
>>
>
> _______________________________________________
> PhotoFloat mailing list
> PhotoFloat at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/photofloat
>
>



More information about the PhotoFloat mailing list