Member
In my archive view, and in the DB, my pictures have the wrong date. The folders and pictures within my "Albums" directory are correct, but in the DB, I have a ton of entries that, I think, date back to an earlier upgrade of ZenPhoto. (I started with version 0.5 or something like that)
Is there any way to easily reconfigure ZenPhoto so that it just grabs the dates using the creation date of each album/photo in the filesystem?
Thanks!
Is there any way to easily reconfigure ZenPhoto so that it just grabs the dates using the creation date of each album/photo in the filesystem?
Thanks!
Member
The easiest way to fix this is to drop the `mtime` field in your images table (and maybe your albums table) then run the upgrade.php program. Note: due to a bug in the 1.1.2 upgrade program you will get an error from mySQL regarding a duplicate entry in the options table. You can ignore this error. Or you can download the nightly build and run the latest and greatest zenphoto. (At your own risk, of course.)
Nightly build is found here: http://www.zenphoto.org/files/nightly/
Nightly build is found here: http://www.zenphoto.org/files/nightly/
Member
Member
Member
Okay, I figured out what's going on. Here's what came from a 'stat' on that file:
Access: 2007-12-12 14:16:26.000000000 -0800
Modify: 2006-03-23 10:44:26.000000000 -0800
Change: 2006-11-07 10:16:52.000000000 -0800
Zenphoto is identifying files by their ctime, rather than their mtime. It seems to me that mtime is a more useful time for zenphoto to use, because it represents (most likely) the actual modification date of the file. File restores, etc. can alter the ctime but usually preserve the mtime. Plus you can manually change mtime using 'touch', which makes it all the more useful if you want to keep your albums properly date-tagged.
I'd call this a bug, personally. What do you think?
Access: 2007-12-12 14:16:26.000000000 -0800
Modify: 2006-03-23 10:44:26.000000000 -0800
Change: 2006-11-07 10:16:52.000000000 -0800
Zenphoto is identifying files by their ctime, rather than their mtime. It seems to me that mtime is a more useful time for zenphoto to use, because it represents (most likely) the actual modification date of the file. File restores, etc. can alter the ctime but usually preserve the mtime. Plus you can manually change mtime using 'touch', which makes it all the more useful if you want to keep your albums properly date-tagged.
I'd call this a bug, personally. What do you think?
Member
Okay, an update: It looks like zenphoto is inconsistent in which date it picks up. In some parts of class-gallery and class-image, it uses mtime, and in other places it picks up ctime. I edited class-gallery.php (line 363) and class-image.php (line 61), changing 'filectime' to 'filemtime' and now everything works perfectly after dropping 'date' and 'mtime' from the images table and then running the upgrade process.
I then ran the following update to set the albums to the appropriate date for the images (so as to sort properly in the gallery):
`update albums, (select albumid, max(mtime) as mtime, max(date) as date from images group by albumid) as i
set albums.mtime = i.mtime, albums.date = i.date
where albums.id = i.albumid`
The end result is just what I wanted. Everything's dated appropriately, and the gallery sorts automatically in chronological order. Beautiful!
I guess now I need to figure out how to put these changes into the subversion repository... Any chance someone else wants to do it for me? Please?
I then ran the following update to set the albums to the appropriate date for the images (so as to sort properly in the gallery):
`update albums, (select albumid, max(mtime) as mtime, max(date) as date from images group by albumid) as i
set albums.mtime = i.mtime, albums.date = i.date
where albums.id = i.albumid`
The end result is just what I wanted. Everything's dated appropriately, and the gallery sorts automatically in chronological order. Beautiful!
I guess now I need to figure out how to put these changes into the subversion repository... Any chance someone else wants to do it for me? Please?
Member
The two values `filemtime` and `filectime` are being used for quite different purposes.
`filemtime` is beign used to try to detect that an image has "changed" somehow and we should refresh the database with new image information. This is why I suggested dropping the mtime field--it would cause a refresh of the db.
`filectime` is used as a default setting for the `date` field in the database. It is of course argueable if this is the correct choice, but it is a first guess. It is more likely to be the data the file was uploaded, which is an approximation for the date shot. If the image has EXIF or IPTC data that includes date information, then that is the value that will be put in the `date` field. The `date` field's intent is that it is the shooting date of the image.
So, what you are in effect doing with your change is to order your images by the date they were last touched. An interesting concept, but maybe not all that generally useful.
The SVN has some new fields you can use for sort order. Perhaps you could consider sorting your images and albums by ID. This will put them in the order they were created in the database--also a close approximation of the upload order.
`filemtime` is beign used to try to detect that an image has "changed" somehow and we should refresh the database with new image information. This is why I suggested dropping the mtime field--it would cause a refresh of the db.
`filectime` is used as a default setting for the `date` field in the database. It is of course argueable if this is the correct choice, but it is a first guess. It is more likely to be the data the file was uploaded, which is an approximation for the date shot. If the image has EXIF or IPTC data that includes date information, then that is the value that will be put in the `date` field. The `date` field's intent is that it is the shooting date of the image.
So, what you are in effect doing with your change is to order your images by the date they were last touched. An interesting concept, but maybe not all that generally useful.
The SVN has some new fields you can use for sort order. Perhaps you could consider sorting your images and albums by ID. This will put them in the order they were created in the database--also a close approximation of the upload order.
Member
Unfortunately, thanks to the "archive" view (which is a fantastic way to view your images) simple sortation isn't the only problem with having the wrong datestamp.
I think ctime is a problematic way to approximate the date of a picture's creation, as ctime is an unreliable measure of a file's creation date. It's simply a system representation of the date that the inode for the file was created.
While some operating systems (MacOS X, for example) have a separate "date created" timestamp on files that is separate from the date the particular instance of the file was created, most Unixes have no equivalent. We can only tell the date of a distinct instance of a file on a given filesystem.
In MOST cases, mtime should match ctime in the case of an uploaded file (it was last modified and created when copied from the user's camera, and again, modified and uploaded at the same time). Unless the core file is updated on the server (an odd thing to do once it's already in a photo gallery), the mtime and ctime ought never to be out of sync.
So, from a functional perspective, mtime seems more useful because it can be reliably maintained through backup and restore processes and is also user-modifiable, so users can sort their photos as they wish. And in most cases, mtime and ctime would be in sync, anyhow, so from a general usability standpoint, the gallery would work as expected.
In my case, I had to recover my files from a backup, so each was created as a new inode (on a new filesystem, for that matter), with updated ctimes. The files themselves were last modified on upload date (the restore process correctly maintained all the file metadata it could).
Of course, if EXIF data is present, none of this is an issue. Many of my files lack this information because they went through batch changes from RAW to JPEG to simplify uploading, and the program I used didn't maintain that metadata. Now I know better.
I think ctime is a problematic way to approximate the date of a picture's creation, as ctime is an unreliable measure of a file's creation date. It's simply a system representation of the date that the inode for the file was created.
While some operating systems (MacOS X, for example) have a separate "date created" timestamp on files that is separate from the date the particular instance of the file was created, most Unixes have no equivalent. We can only tell the date of a distinct instance of a file on a given filesystem.
In MOST cases, mtime should match ctime in the case of an uploaded file (it was last modified and created when copied from the user's camera, and again, modified and uploaded at the same time). Unless the core file is updated on the server (an odd thing to do once it's already in a photo gallery), the mtime and ctime ought never to be out of sync.
So, from a functional perspective, mtime seems more useful because it can be reliably maintained through backup and restore processes and is also user-modifiable, so users can sort their photos as they wish. And in most cases, mtime and ctime would be in sync, anyhow, so from a general usability standpoint, the gallery would work as expected.
In my case, I had to recover my files from a backup, so each was created as a new inode (on a new filesystem, for that matter), with updated ctimes. The files themselves were last modified on upload date (the restore process correctly maintained all the file metadata it could).
Of course, if EXIF data is present, none of this is an issue. Many of my files lack this information because they went through batch changes from RAW to JPEG to simplify uploading, and the program I used didn't maintain that metadata. Now I know better.