134 Type Error: ... - jAlbum forums

This thread is locked - replies are not allowed.

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

Search Forum

Back to Thread List

Replies: 22 - Pages: 2 [ Previous | 1 2 ] - Last Post: 2 Jan 25, 00:20 Last Post By: kilobravo

RobM

Posts: 3,891
Registered: 4-Aug-2006

Re: 134 Type Error:
Posted: 31 Dec 24, 20:13

in response to: kilobravo

This logging level is just for help in debugging, generally it should be left at 'Warning'.

The 'INFO: No representing image in folder...' will appear when you have deselected 'Settings > Advanced > Use thumbnail for folder icon'. As it says, it is just for info., when logging is set to 'Warning' that would not be shown.

By 'co-incidence' that setting is what sections.inc line 5 appears to be looking at:

	var	getFolderThumb = function(ao) {
				var vars = ao.getVars(),
					s;
				// Iconpath => SVG, folder thumb path
				if (s = vars.get('iconPath')) {
					s = s.replace('folder.png', defaultFolderIconName);
					return s.replace(/^\.\.\//, '');
				} else {
					return createFolderThumb(ao, folderThumbSize, true);
				}
			},

Something for Laza to look at.

kilobravo

Posts: 179
Registered: 24-Feb-2010

Re: 134 Type Error:
Posted: 31 Dec 24, 20:17

in response to: RobM

Appreciate the explanations Rob but I checked and I do not have "Use Thumbnaail for folder icon" unchecked or rather skipping the double negative <smile> that option IS checked so not sure why it was called out.

Roger on this being something for Laza, thanks for that too.

HNY!

Laza

Posts: 1,456
Registered: 6-Sep-2005

Re: 134 Type Error:
Posted: 1 Jan 25, 10:35

in response to: RobM

I have checked it lately, but if s.replace drops a type error, that means vars.get('iconPath') returns a non-string value (not null), which should never happen. I guess this is because, at a previous step, jAlbum crashes, and the AlbumObject is garbage.

RobM

Posts: 3,891
Registered: 4-Aug-2006

Re: 134 Type Error:
Posted: 1 Jan 25, 12:40

in response to: Laza

A common problem seems to be with JDeli, after an index out of bounds error there is an OutOfMemoryError: Java heap space. Could JDeli error handling be the root cause?

Some examples from above:

Usingcom.idrsolutions.JDeliImageWriter Error:Index 86 out of bounds for length 19
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: Java heap space

Usingcom.idrsolutions.JDeliImageWriter Error:Index 86 out of bounds for length 19
Error appending xmp metadata to dusk-oso-pano_180912.jpg. Metadata too large for one 64KB segment (67002 bytes)

java.lang.OutOfMemoryError: Java heap space
at java.base/java.util.ArrayList.<init>(Unknown Source)
at com.idrsolutions.image.webp.enc.FullGenArrPointer.<init>(FullGenArrPointer.java:14)

Laza

Posts: 1,456
Registered: 6-Sep-2005

Re: 134 Type Error:
Posted: 1 Jan 25, 13:32

in response to: RobM

It could be JDeli, for sure. (Only David can tell.) If turning off "Include photographic data in generated pages" fixes it, it's probably JDeli.

kilobravo

Posts: 179
Registered: 24-Feb-2010

Re: 134 Type Error:
Posted: 1 Jan 25, 16:43

in response to: Laza

This was my second go around with .webp and like the first time, those conversions seem to have been at the root of my stalling and crashing issues. I say this because when I changed both albums back to JPG's only, JA worked as advertised on both makes and uploads.

It would seem that in my case, the outofmemory error and Java heap space were directly related to the .webp routines and especially due to some very large image files I asked it to convert. And, while I'd always like to reduce image file sizes to minimize server storage, the ISP plan I have now gives me a lot of head room and .webp size reduction isn't necessary. Seems I tortured myself once again for no reason. <laughing>

Thank you to all who put up with my issues and offered suggestions.

JeffTucker

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

Re: 134 Type Error:
Posted: 1 Jan 25, 16:56

in response to: kilobravo

It's even worse than that. The current version of the WEBP conversion routine does such a poor job, you need to crank up the WEBP Quality to match the quality of a JPG scaled image. And at that point, the WEBP files aren't even smaller than the JPG's. So why bother with it at all?

I strongly believe that this option should be removed from jAlbum completely. It doesn't work very well, it's slow, and it's increasingly unnecessary. Even if WEBP produced smaller files of comparable quality, storage and bandwidth are either cheap or free. Commercial sites might use it, because with millions of visitors, their bandwidth isn't free. But for jAlbum users, it's a non-issue.

kilobravo

Posts: 179
Registered: 24-Feb-2010

Re: 134 Type Error:
Posted: 2 Jan 25, 00:20

in response to: JeffTucker

I also compared file sizes between .webp and .jpg and got the same results, Jeff which is why I disabled them. Your logic is sound and if/until the conversion coding improves to the point where the files are considerably smaller while maintaining jpg quality, I don't see the point in having in JA, either.

Pages: 2 [ Previous | 1 2 ]

Back to Thread List

Legend
	Forum admins
	Helpful Answer
	Correct Answer