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


Permlink Replies: 21 - Pages: 2 [ 1 2 | Next ] - Last Post: 24 Feb 26, 23:54 Last Post By: kilobravo
kilobravo

Posts: 179
Registered: 24-Feb-2010
V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 11 Jan 26, 16:51
 
  Click to reply to this thread Reply
Attachment lifeboat.zip (845.9 KB)
Like a moron, I decided to change the structure of my two main albums but only changed the number/row of tn's and even though I got the "like, we're gonna havta redo ALL those darn images again, Sailor" dialog boxes followed by a Make Album as usual.

Off it went and the numbers told the story that it would be some time so I started reading the news. Somewhere down the line, JA39 simply locked up which has now happened three times in a row. Have done all the standard Windoze-style "clearings" including a cold boot of the PC.

That said, based on my terrible track record, I'm certain that Jeff or Rob are gonna tell me exactly what I'm doing wrong or, what the culprit might be. The index page for both albums is here. <pulling on my rusty, dusty suit of armor.. ;+)

Both albums use the same skin and thanks for the mention of "Save Skin as "XXX" default." This will save me enormous amounts of time because I lose track of what I've changed on which. I know, personal problem with which I shall try to deal but I do hope one of you giants of the coding industry can get me "Makin'" again? TIA
RobM

Posts: 3,901
Registered: 4-Aug-2006
Re: V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 11 Jan 26, 17:18   in response to: kilobravo in response to: kilobravo
 
  Click to reply to this thread Reply
If you are still getting stalls/crashing, when it happens open the system console and hit the "Dump threads" button. Then press CMD/Cntrl + C, to open jAlbum's 'config' folder and look for a file called 'thread-dump.txt'. Post that along with any error message in the system console.

You could also try reducing the number of threads used under Preferences > Advanced > Number of threads. If it’s set at the maximum and you’re regenerating images then maybe that’s causing a memory issue. Just a guess.
RobM

Posts: 3,901
Registered: 4-Aug-2006
Re: V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 11 Jan 26, 17:26   in response to: kilobravo in response to: kilobravo
 
  Click to reply to this thread Reply
kilobravo wrote:
Both albums use the same skin and thanks for the mention of "Save Skin as "XXX" default." This will save me enormous amounts of time because I lose track of what I've changed on which…
What may help with identifying changes is to copy the jabum-settings files to new text documents, sort the text alphabetically and then do a compare documents. Having found a difference then go to https://jalbum.net/help/en/GUI_Settings_and_jalbum-settings.jap
That tells you what gui setting is mapped to the .jap file.

Note though, I’ve not yet had time to update it for changes in v39.
kilobravo

Posts: 179
Registered: 24-Feb-2010
Re: V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 11 Jan 26, 17:55   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
Thanks for that most valuable tip, Rob..you may have saved me from an early grave. <smile>
kilobravo

Posts: 179
Registered: 24-Feb-2010
Re: V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 12 Jan 26, 12:30   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
I had never noticed the "Dump Threads" button before, Rob but I was able to use it for this issue and this is the error message and reason for the crashes.

"Exception in thread "Disposer" java.lang.OutOfMemoryError: Java heap space"

I hadn't seen this error previously either but it caused me to check the jalbum.ini file again and I was surprised to see that the Xmx variable was reset to 2000 despite me upping it multiple times recently. Does it do this after program updates like the new v39 fresh start? If so, that would explain the change.

Each time the program locked up on me, it would get further into the Make each time I restarted the machine and then restarted JA. After I changed the Xmx to 8000, the Make finished but it might also have finished without an error because there weren't many file operations remaining in the Make. I'd rather not do a Force Remake to troubleshoot as they take a good while on that album due to the number of images, which is around 16k.

I'll mark the question answered now that I know it was once again a heap space issue and report back if it continues. Thanks again, Rob!
davidekholm

Posts: 3,844
Registered: 18-Oct-2002
Re: V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 12 Jan 26, 13:21   in response to: kilobravo in response to: kilobravo
 
  Click to reply to this thread Reply
kilobravo wrote:
I had never noticed the "Dump Threads" button before, Rob but I was able to use it for this issue and this is the error message and reason for the crashes.

"Exception in thread "Disposer" java.lang.OutOfMemoryError: Java heap space"

I hadn't seen this error previously either but it caused me to check the jalbum.ini file again and I was surprised to see that the Xmx variable was reset to 2000 despite me upping it multiple times recently. Does it do this after program updates like the new v39 fresh start? If so, that would explain the change.


The new default is 8000 so I can't explain why it was down to 2000 in jAlbum.ini really.
RobM

Posts: 3,901
Registered: 4-Aug-2006
Re: V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 12 Jan 26, 13:23   in response to: kilobravo in response to: kilobravo
 
  Click to reply to this thread Reply
Glad it’s sorted. The .ini file would need updating after a new install, but the value should be set to 8000 by default.
JeffTucker

Posts: 8,081
Registered: 31-Jan-2006
Re: V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 12 Jan 26, 14:19   in response to: kilobravo in response to: kilobravo
 
  Click to reply to this thread Reply
kilobravo wrote:
I hadn't seen this error previously either but it caused me to check the jalbum.ini file again and I was surprised to see that the Xmx variable was reset to 2000 despite me upping it multiple times recently. Does it do this after program updates like the new v39 fresh start? If so, that would explain the change.

You've been visited by App Trolls™.
kilobravo

Posts: 179
Registered: 24-Feb-2010
Re: V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 12 Jan 26, 15:03   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
Thanks for the update on the Xms variable guys and no eye deer why it was down to 2k. I have only ever UPped the value.

I also tried reducing transfer threads from 8 to 6 to 4 but nothing changed so I went back to 8. Currently waiting on the last upload of the larger album so it looks like that part of the problem is solved with the heap space bump. Yep, just finished, no errors and the upploaded album appears to match the Make result.

As always, many thanks for the expert help and patience with forgetful OG's like yours truly.
phil44

Posts: 170
Registered: 18-Jun-2010
Re: V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 12 Jan 26, 18:24   in response to: kilobravo in response to: kilobravo
 
  Click to reply to this thread Reply
This kind of problem could easily be solved with a custom jAlbum.ini file in the config directory, taking precedence over the file in the installation directory (easy to do in Java). Of course, the file in the config directory would only contain entries requiring specific values.

It's just a wish for a future version ;-)
davidekholm

Posts: 3,844
Registered: 18-Oct-2002
Re: V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 12 Jan 26, 19:08   in response to: phil44 in response to: phil44
 
  Click to reply to this thread Reply
I get your reasoning, however, this part of jAlbum is controlled by the installer's launcher file ("jAlbum.exe") which isn't made by us but by AdvancedInstaller. However, I can check with them
kilobravo

Posts: 179
Registered: 24-Feb-2010
Re: V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 18 Feb 26, 16:29   in response to: kilobravo in response to: kilobravo
 
  Click to reply to this thread Reply
MAKEs are locking up again, dang it!

I've gone through all the source images and deleted quite a few to include very large JPG's and even a couple .PSD's. No help. Tried to do a Thread Dump but couldn't because JA was locked up tight and I had to use the Windoze Task Manager to end the task.

Checked the xms memory parameter and it was back to 8k so I upped it to 16k. That seemed to help but as the next Make got closer to finishing, the counter slowed down and I decided to try a Thread Dump before the app froze. I've attached the dump file but since the Make was still in progress albeit very slowly, I have a feeling the dump file won't be much help.

Upped the xms parm again to 24k and tried another Make. It got a lot further along but ultimately locked JA up again.

Sorry to be a pain..but thanks in advance.

BTW, Rob, I'm really getting some mileage out of the "sort alphabetically" tip when combining two settings files. Definitely saves time digging around looking for differences in two albums so thanks again for that.
davidekholm

Posts: 3,844
Registered: 18-Oct-2002
Re: V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 19 Feb 26, 10:10   in response to: kilobravo in response to: kilobravo
 
  Click to reply to this thread Reply
Let's investigate this:
First, I hope you mean 8G, not 8k. Please double-check
Second, ensure you use the "Background mode" when building so the UI is usable during builds (See Preferences-Background mode)
Third, After a few minutes of building, select Tools->External tools->Perform garbage collection. It the total RAM used ever goes above 8GB then we most likely have a memory leak we need to pinpoint. If RAM usage stays modest when (for test) switching to JPEG, then the leak is likely with the AVIF writer

By the way, we make two AVIF writers available, but I (by now) only recommend you to use the standard "aom" writer. See Preferences->Advanced->AVIF
kilobravo

Posts: 179
Registered: 24-Feb-2010
Re: V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 19 Feb 26, 12:37   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
First, thanks for the reply, David. I have two albums with very uncommon names..Newer and Older. smile They contain approximately 6k and 14k images respectively.

Second, yes I meant GB not k. Didn't realize the "M" suffix and currently I have:

Virtual Machine Parameters=-Xms256M -Xmx16000M

And, I was able to finish a Make on the Older album this morning but it took a lot longer (20 mins or so,) than I'm used to and the upload looks like it will take hours. But during the Make I did a number of garbage dumps. However, the Make on the Newer album crashed about a third of the way through and yes, I always use Background Makes and Uploads.

Here are the respective garbage dumps for each of the albums:

Making "newer album" (All)
Garbage collection result
Total: 16000 MB. Used: 11404 MB
Garbage collection result
Total: 1442 MB. Used: 352 MB
Garbage collection result
Total: 4572 MB. Used: 1251 MB
Garbage collection result
Total: 12672 MB. Used: 4114 MB
Crashed and didn't finish.

Making "older album" (All)
Garbage collection result
Total: 7616 MB. Used: 2370 MB
Garbage collection result
Total: 8568 MB. Used: 3051.19 MB
Garbage collection result
Total: 8136 MB. Used: 2362.19 MB
Garbage collection result
Total: 8712 MB. Used: 2572.27 MB
Garbage collection result
Total: 6328 MB. Used: 2011.13 MB
Garbage collection result
Total: 8376 MB. Used: 2437.61 MB

Totally unrelated I presume but after the Older album Make, my Theme Image was missing and only the text for the album title was visible.

I am impressed with the .AVIF format in terms of saving storage but I'm wondering if the conversions are the reasons for the painfully slow performance?

Thanks again, David and I hope some of this info helps with TS'ing.
davidekholm

Posts: 3,844
Registered: 18-Oct-2002
Re: V39 Make Album Crashes (or is that Crashi? ;=))
Posted: 19 Feb 26, 13:16   in response to: kilobravo in response to: kilobravo
 
  Click to reply to this thread Reply
AVIF can be both fairly fast and slow depending on the speed settings. (I now use 8). I think the RAM issue (memory leak) most likely will cause a painful slowdown when the Java engine spends more and more time freeing up memory than doing real processing. I have identified a memory leak during the "make album" process that's unrelated to image processing. It starts in v38, so I'm investigating the cause of this leak now. Will keep you posted.
Legend
Forum admins
Helpful Answer
Correct Answer

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