This question is answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 36 - Pages: 3 [ Previous | 1 2 3 | Next ] - Last Post: 30 Oct 23, 10:11 Last Post By: davidekholm Threads: [ Previous | Next ]
JeffTucker

Posts: 7,942
Registered: 31-Jan-2006
Re: Missing originalDate
Posted: 24 Oct 23, 17:17   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
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:

davidekholm

Posts: 3,668
Registered: 18-Oct-2002
Re: Missing originalDate
Posted: 24 Oct 23, 17:20   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
:-)

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
JeffTucker

Posts: 7,942
Registered: 31-Jan-2006
Re: Missing originalDate
Posted: 24 Oct 23, 17:24   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
One wouldn't think that something so small could produce such bad effects, but apparently it does. Truly a head-scratcher.
JeffTucker

Posts: 7,942
Registered: 31-Jan-2006
Re: Missing originalDate
Posted: 24 Oct 23, 17:36   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Attachment pa008.jpg (3.4 MB)
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.
davidekholm

Posts: 3,668
Registered: 18-Oct-2002
Re: Missing originalDate
Posted: 24 Oct 23, 17:45   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
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
JeffTucker

Posts: 7,942
Registered: 31-Jan-2006
Re: Missing originalDate
Posted: 24 Oct 23, 17:51   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
What should the core size be? Do I actually have the right version?
davidekholm

Posts: 3,668
Registered: 18-Oct-2002
Re: Missing originalDate
Posted: 25 Oct 23, 12:44   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
To avoid doubt. I've bumped the revision to 33.0.8. The core file size is 4868290 bytes
JeffTucker

Posts: 7,942
Registered: 31-Jan-2006
Re: Missing originalDate
Posted: 25 Oct 23, 13:52   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
Attachment normal.png (7.8 KB)
Attachment zerodate.png (9.7 KB)
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.
JeffTucker

Posts: 7,942
Registered: 31-Jan-2006
Re: Missing originalDate
Posted: 25 Oct 23, 14:02   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Attachment fixed.png (7.9 KB)
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!).
davidekholm

Posts: 3,668
Registered: 18-Oct-2002
Re: Missing originalDate
Posted: 25 Oct 23, 14:18   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
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)
JeffTucker

Posts: 7,942
Registered: 31-Jan-2006
Re: Missing originalDate
Posted: 25 Oct 23, 14:27   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
Attachment w13.jpg (453.7 KB)
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.
davidekholm

Posts: 3,668
Registered: 18-Oct-2002
Re: Missing originalDate
Posted: 25 Oct 23, 14:44   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
JeffTucker wrote:
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.
JeffTucker

Posts: 7,942
Registered: 31-Jan-2006
Re: Missing originalDate
Posted: 25 Oct 23, 14:46   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
davidekholm wrote:
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
RobM

Posts: 3,967
Registered: 4-Aug-2006
Re: Missing originalDate
Posted: 25 Oct 23, 14:50   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
davidekholm wrote:
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.
davidekholm

Posts: 3,668
Registered: 18-Oct-2002
Re: Missing originalDate
Posted: 28 Oct 23, 14:51   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
RobM wrote:
davidekholm wrote:
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

Point your RSS reader here for a feed of the latest messages in all forums