jAlbum 20.1 beta for testing ...

davidekholm

Posts: 4,317
Registered: 18-Oct-2002

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 17:32

in response to: JeffTucker

jGromit wrote:

Oh, who am I kidding? These are precisely the users who will demand extensive hand-holding.

If we're to "move" files between drive letters, that's really a copy operation followed by a delete operation and not even the file manager does that. It does the copy for you, but leaves it up to you to delete the source folder. For this reason, I think we shouldn't do users the "service" of starting a potentially big copy-followed-by-delete operation if they change the location of the album folder to another drive letter. They don't have to be clever about it, just hit "Make album" thereafter and the album is re-generated in the new location. Power users who wish to avoid a full album make are probably clever enough to understand to manually copy the album folder from the old location to the new.

JeffTucker

Posts: 8,321
Registered: 31-Jan-2006

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 17:37

in response to: davidekholm

davidekholm wrote:
Power users... are probably clever enough to understand....

Your faith is truly inspiring. Hilarious, but inspiring.

ctwist

Posts: 497
Registered: 27-Sep-2003

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 17:40

in response to: davidekholm

davidekholm wrote:
Isn't the current scheme safe enough? We only move the physical album folder if the target folder is either missing or empty.

I don't think so. I am concerned that the source album folder may be used by another project.

E.g.
Project 1 saves its album in "Documents\albums\project1"

Project 2 is configured to make the album in "Documents\My Projects\project2\album".
The user changes this to "Documents\albums\project1" and saves the project settings.
He then realizes his mistake and changes this to "Documents\albums\project2". jAlbum should not move the album folder in these circumstances.

Another point:
I don't know when the moving of an album folder occurs. It should happen either at the beginning of "make album" or when the user saves the project settings. This allows the user to make multiple corrections to the folder location before the move occurs.

AndreWolff

Posts: 2,356
Registered: 14-Dec-2007

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 18:01

in response to: davidekholm

ErrorStack.txt (1.7 KB)

davidekholm wrote:
I need to see a longer stack trace.

Version 20.1b18 gives the attached error log

AndreWolff

Posts: 2,356
Registered: 14-Dec-2007

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 18:04

in response to: RobM

RobM wrote:
It might be better to not let subfolders have a res folder, either have them ignored or shown but as permanently excluded.

That is in my eyes a good solution.

davidekholm

Posts: 4,317
Registered: 18-Oct-2002

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 18:04

in response to: ctwist

ctwist wrote:

Another point:
I don't know when the moving of an album folder occurs. It should happen either at the beginning of "make album" or when the user saves the project settings. This allows the user to make multiple corrections to the folder location before the move occurs.

The move is taking place when the user has made changes to the location of the album folder and closes the settings window, or hits the apply button of the settings window.

davidekholm

Posts: 4,317
Registered: 18-Oct-2002

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 18:10

in response to: AndreWolff

AndreWolff wrote:

davidekholm wrote:
I need to see a longer stack trace.

Version 20.1b18 gives the attached error log

Not much to go on there (no reference to jAlbum code, apart from generic script processing). Are you SURE this problem doesn't occur if you keep v20 installed in parallel and try with it instead, making NO other changes (like skin or skin version)? I think it's a red herring that an out-of-memory condition has been introduced in v20.1, especially as it's triggered during script processing and I haven't modified anything related to script processing in v20.1.

When you get an out of memory condition, always follow up with a garbage collection and pass the generated report to your report in this forum. The garbage collection report is generated to jAlbum's system console. It will tell how much RAM jAlbum has allocated and how much is free. It gives me a better understanding if the error is related to fragmented RAM for instance.

ctwist

Posts: 497
Registered: 27-Sep-2003

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 18:11

in response to: davidekholm

davidekholm wrote:

ctwist wrote:

The move is taking place when the user has made changes to the location of the album folder and closes the settings window, or hits the apply button of the settings window.

I don't think it should occur when he closes the settings window, since this doesn't allow him to correct a mistake in the changed album folder location.
Some other changes to album settings do not take effect immediately (you are prompted to save when closing the project). I think that changes to the album folder location should be handled in the same way.

davidekholm

Posts: 4,317
Registered: 18-Oct-2002

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 18:13

in response to: ctwist

Is this a case where the majority votes for a pop up confirmation dialogue perhaps?

JeffTucker

Posts: 8,321
Registered: 31-Jan-2006

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 18:15

in response to: davidekholm

davidekholm wrote:
Is this a case where the majority votes for a pop up confirmation dialogue perhaps?

Wouldn't be a bad idea:

"Should I move the existing output to ${newPath}?", with a default to Yes.

ctwist

Posts: 497
Registered: 27-Sep-2003

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 18:19

in response to: JeffTucker

That would be better.

AndreWolff

Posts: 2,356
Registered: 14-Dec-2007

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 18:35

in response to: davidekholm

	CarbageCollection.JPG (33.4 KB)
	ErrorStack.txt (4.0 KB)

davidekholm wrote:
When you get an out of memory condition, always follow up with a garbage collection and pass the generated report to your report in this forum. The garbage collection report is generated to jAlbum's system console. It will tell how much RAM jAlbum has allocated and how much is free. It gives me a better understanding if the error is related to fragmented RAM for instance.

Sorry, you should explain this for me: How do I start the garbage collection?
It would also help if the sytem gives the full path of the image processed during the crash!

Edit:
I found it, results attached.

Edited by: AndreWolff on 13-May-2020 18:40

davidekholm

Posts: 4,317
Registered: 18-Oct-2002

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 19:01

in response to: AndreWolff

AndreWolff wrote:

davidekholm wrote:
When you get an out of memory condition, always follow up with a garbage collection and pass the generated report to your report in this forum. The garbage collection report is generated to jAlbum's system console. It will tell how much RAM jAlbum has allocated and how much is free. It gives me a better understanding if the error is related to fragmented RAM for instance.

Sorry, you should explain this for me: How do I start the garbage collection?
It would also help if the sytem gives the full path of the image processed during the crash!

Edit:
I found it, results attached.

Great. Well 5GB free RAM should do it unless you have enormous images. The error is occurring during script processing. Is it your skin perhaps? In that case, wrap the script in a large try-catch block where you catch the OutOfMemoryError, then print the relevant file name. I think this piece of code reference will guide you to the culprit:

strippedAlbumDescription=removeLinks(strippedAlbumDescription);

AndreWolff

Posts: 2,356
Registered: 14-Dec-2007

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 19:29

in response to: davidekholm

WindowTooShortJPG.JPG (40.1 KB)

davidekholm wrote:
Great. Well 5GB free RAM should do it unless you have enormous images. The error is occurring during script processing. Is it your skin perhaps?

I don't think so, because this was no problem under jAlbum 20.0.6 and I did not change the skin code.

In that case, wrap the script in a large try-catch block where you catch the OutOfMemoryError, then print the relevant file name. I think this piece of code reference will guide you to the culprit:

strippedAlbumDescription=removeLinks(strippedAlbumDescription);

I realy have no idea how to do that.
It is the latest release of the FancyBox skin, so why don't you do that yourself and pass me the jaskin file to test it?

Edit:
I can do something with the text in the status line, see attached screenshot, but the displayed text is too short. Why don't display you the full text?

Anyhow if I exclude the added image, the crash comes later.

Edit 2:
The problem image Algarve_120212_1317.jpg from my directory I:\Pictures\Algarve\Algarve_2008\108 is too large to be added.
This is a panoramic image of size 26035x3090 and size 15.7 MB

Here is the corresponding slide page made wiuth jAlbum 20.0.6:
https://www.andrewolff.nl/FotoSerie/Algarve/Algarve_2008/108/index.html#S-17

Edit 3:
I did mail the problem image to you.

Edit 4:

If I use the Slide Show 4 skin instead of the FancyBox skin, I get the same crash.

Edited by: AndreWolff on 13-May-2020 20:46

davidekholm

Posts: 4,317
Registered: 18-Oct-2002

Re: jAlbum 20.1 beta for testing
Posted: 13 May 20, 23:22

in response to: AndreWolff

I made 96 copies of that large panoramic image you passed me and made an album using FancyBox and smooth scaling (the most memory consuming scaling). It required under 4GB using 4 threads. No out of memory condition.

It's easier if you debug as you can reproduce this one. I still recommend you to try the same project on jAlbum 20 if you claim that the problem was introduced with 20.1. I personally think that's a red herring. Pass me your project file too and I'll test with it too. It might contain some setting that requires even more RAM (an image filter for instance).

As the skin is your code ,and you know the code paths it has, it's better that you wrap code sections you wish to test in try-catch clauses. If you don't know about Java try-catch clauses, just google it. They are a great help!