Posts:
7,942
Registered:
31-Jan-2006
|
|
|
Re: Missing originalDate
Posted:
24 Oct 23, 17:17
in response to: davidekholm
|
|
|
Yup, back to normal, expected behavior.
We can return to the "zero date" images at another time, when there aren't as many other things going on. I'm working on new releases of 5 skins with some tricky JS (and just a single missing curly brace can blow a page completely out of the water!), plus I'm in an extended email exchange with a "tinkerer" - a good mental exercise in doing custom CSS, but time-consuming!
But that's why you pay me the big bucks. I've cleared a spot in my garage so I can take delivery:

|
|
|
Posts:
3,668
Registered:
18-Oct-2002
|
|
|
Re: Missing originalDate
Posted:
24 Oct 23, 17:20
in response to: JeffTucker
|
|
|
I found the error .There was a missing return statement. I've done another core update now.
Edited by: davidekholm on 24 Oct 2023, 17:21
|
|
|
Posts:
7,942
Registered:
31-Jan-2006
|
|
|
Re: Missing originalDate
Posted:
24 Oct 23, 17:24
in response to: davidekholm
|
|
|
One wouldn't think that something so small could produce such bad effects, but apparently it does. Truly a head-scratcher.
|
|
|
Posts:
7,942
Registered:
31-Jan-2006
|
|
|
Re: Missing originalDate
Posted:
24 Oct 23, 17:36
in response to: JeffTucker
|
|
|
|
I've got so many core files kicking around, I no longer know what the hell I'm doing. I went back to 33.0.6 and did a core update. It reads 33.0.7, and the size is 4,868,291.
With proper images, it works fine. But with a "zero date" image, it's not rejecting the date. It's displaying Nov. 30, 0002, and albumfiles.txt contains: pa008.jpg 1698161367 -62170138800
You've edited out the code you were showing, but from my dim short-term memory, I think it was doing something like: if(date == -62170138800L) do something
But shouldn't it be doing a string comparison? Just guessing.
|
|
|
Posts:
3,668
Registered:
18-Oct-2002
|
|
|
Re: Missing originalDate
Posted:
24 Oct 23, 17:45
in response to: JeffTucker
|
|
|
With your "pa008.jpg " image, the date is indeed rejected and not written to albumfiles.txt.
I'm using == because the date is in long format (i.e. the long data type): d.getTime() == -62170160400000L
|
|
|
Posts:
7,942
Registered:
31-Jan-2006
|
|
|
Re: Missing originalDate
Posted:
24 Oct 23, 17:51
in response to: davidekholm
|
|
|
What should the core size be? Do I actually have the right version?
|
|
|
Posts:
3,668
Registered:
18-Oct-2002
|
|
|
Re: Missing originalDate
Posted:
25 Oct 23, 12:44
in response to: JeffTucker
|
|
|
To avoid doubt. I've bumped the revision to 33.0.8. The core file size is 4868290 bytes
|
|
|
Posts:
7,942
Registered:
31-Jan-2006
|
|
|
Re: Missing originalDate
Posted:
25 Oct 23, 13:52
in response to: davidekholm
|
|
|
|
I give up. It's correctly extracting the "good dates" from normal image files, and that's what really matters. It's also extracting the "bad dates" from the somewhat mangled Olympus image files, but if that creates a problem for an album creator, there are some wonderful apps out there that can correct the problem. I use one called Attribute Changer.
I've got 33.0.8. The core size is 4,868,290. I've cleared out the various iterations of .jar.old files, to be doubly sure.
If I add two normal images and one problem child to a project and make the album, albumfiles.txt shows this: # This file is created by jAlbum. It sets custom file filtering and ordering for this image directory.
# Files not listed here are added to the end of the album
# Rows beginning with "-" indicate excluded files.
# Rows can have up to 3 tab separated columns according to this scheme:
# File name | Target path (for links) | When added (seconds since epoch)
# Note: The target path can reference files and directories in other locations and thereby
# allows you to compile albums consisting of files from several different locations.
a01.jpg 1698234233 1329154046
a02.jpg 1698234233 1329161091
pa008.jpg 1698234233 -62170138800
And the skin displays the metadata as per the attached screenshots.
|
|
|
Posts:
7,942
Registered:
31-Jan-2006
|
|
|
Re: Missing originalDate
Posted:
25 Oct 23, 14:02
in response to: JeffTucker
|
|
|
|
And the happy result after manually fixing the file (had to look back at an old travel diary to see when I was in Bariloche!).
|
|
|
Posts:
3,668
Registered:
18-Oct-2002
|
|
|
Re: Missing originalDate
Posted:
25 Oct 23, 14:18
in response to: JeffTucker
|
|
|
Ok but -62170138800 is a different number than I was testing for. Perhaps some time zone trickery is involved here? I simply changed to test for dates older than -60000000000000 now. That should do it. Available as a core update (33.0.9)
|
|
|
Posts:
7,942
Registered:
31-Jan-2006
|
|
|
Re: Missing originalDate
Posted:
25 Oct 23, 14:27
in response to: davidekholm
|
|
|
|
I was just wondering about that. When I pulled up Attribute Changer to fix the date, it was showing as Dec. 30, 1899. Because GMT -5.
But, sadly, no change with 33.0.9. Exactly the same result: -62170138800.
Should it be checking against seconds, or milliseconds?
ETA: For that matter, should it just be checking for anything less than zero, the Java epoch of Jan. 1, 1970? No image file could have a legitimate camera date earlier than that. I suppose a user could have added camera dates to scans of old photos. But if his collection of family photos is anything like mine, just getting the right year on an image is a challenge, to say nothing of a date. Unless someone in the photo is holding up a copy of a newspaper.... Attached photo taken by my father somewhere in Germany.
|
|
|
Posts:
3,668
Registered:
18-Oct-2002
|
|
|
Re: Missing originalDate
Posted:
25 Oct 23, 14:44
in response to: JeffTucker
|
|
|
I was just wondering about that. When I pulled up Attribute Changer to fix the date, it was showing as Dec. 30, 1899. Because GMT -5.
But, sadly, no change with 33.0.9. Exactly the same result: -62170138800.
Are you 100% sure you deleted albumfiles.txt prior to launching v33.0.9?
Should it be checking against seconds, or milliseconds?
The dates written to file are in seconds since epoch, but internally, jAlbum compares milliseconds.
|
|
|
Posts:
7,942
Registered:
31-Jan-2006
|
|
|
Re: Missing originalDate
Posted:
25 Oct 23, 14:46
in response to: davidekholm
|
|
|
Are you 100% sure you deleted albumfiles.txt prior to launching v33.0.9?
I've been testing by starting a new, empty project with nothing in it. Even using a different project name, to be sure.
From just such a project: # This file is created by jAlbum. It sets custom file filtering and ordering for this image directory.
# Files not listed here are added to the end of the album
# Rows beginning with "-" indicate excluded files.
# Rows can have up to 3 tab separated columns according to this scheme:
# File name | Target path (for links) | When added (seconds since epoch)
# Note: The target path can reference files and directories in other locations and thereby
# allows you to compile albums consisting of files from several different locations.
pa008 - corrected.jpg 1698237930 1107802800
pa008.jpg 1698237930 -62170138800
|
|
|
Posts:
3,967
Registered:
4-Aug-2006
|
|
|
Re: Missing originalDate
Posted:
25 Oct 23, 14:50
in response to: davidekholm
|
|
|
Ok but -62170138800 is a different number than I was testing for. Perhaps some time zone trickery is involved here? I simply changed to test for dates older than -60000000000000 now. That should do it. Available as a core update (33.0.9)
Is ‘-60000000000000’ really what you meant? That is 14 digits, the other is 11 digits.
|
|
|
Posts:
3,668
Registered:
18-Oct-2002
|
|
|
Re: Missing originalDate
Posted:
28 Oct 23, 14:51
in response to: RobM
|
|
|
Ok but -62170138800 is a different number than I was testing for. Perhaps some time zone trickery is involved here? I simply changed to test for dates older than -60000000000000 now. That should do it. Available as a core update (33.0.9)
Is ‘-60000000000000’ really what you meant? That is 14 digits, the other is 11 digits.
Yes. Internally I'm comparing milliseconds, but albumfiles.txt uses seconds.
|
|
|
|
Legend
|
|
Forum admins
|
|
Helpful Answer
|
|
Correct Answer
|
|