Not quite sure where this goes... or that it's 'fixable'

When I cleaned out the cache folder for one of my Albums (all the photos that were causing order problems), I saw two versions of each image in cache.

One was .jpg_200.jpg and .jpg_595.jpg. What I wanted to know is, other than taking up space, does having the two sizes cause problems or, when changing settings, should there be way to erase the old?

What creates the sizing of the cache image? The 595 was the image size setting I used originally but never 200. This also maybe why the sort image size is so large?

The 200.jpg is the cached thumbnail and 595.jpg is the cached size image. Both have nothing to do with sorting.
That you have 200 sizes you never use cannot be, maybe you tried another theme or played with the size options, so they where some left over.

Other that time it takes to re-cache, can it be emptied to "start fresh". Then I'll know for sure where they're coming frm. I know the _595.jpg were very old ones, not questioning them. It's the 200 I have question. ALL my albums are "Image size - 450"; Thumb size - 100; so where does the value come from? (My Gallery images are from Default Theme separate from Default Theme Albums and settings are different as one only sees the one image selected to represent each album.)

The sorting code shows the images coming from /cache/.... so thought that's why size was that.

I think it's fine to delete all the files in the /cache
I have setup a cron job to do it once a month.

Does Zenphoto already assign expiry dates to the cache?

No, it doesn't. Generally, if you don'T change your images/sizes, there is bascially no need to cache them again.

I periodically run the following command to find inactive cache files. I could run the output through to rm with a cron job but I've never bothered setting it up.

find zenphoto/cache -type f -atime +90 -size +20 -print

Notes:

1. I don't want to clear the thumbnails from the cache (assuming 20kB is larger than a thumbnail). They're small and recreating the thumbnails makes the browsing experience slow.
2. 90 days since last access sounds reasonable - my galleries are generally event related (holidays/weddings/etc) and get hit when published but very rarely after that.
3. I set up my gallery to load the next 2 images after the current one (hidden on the page) when browsing the image pages. This means that the caching (local to the browser and remote at my server) is usually done before the relevant image page gets requested - not quite galleria/tricasa smooth/fast but works quite well all the same.

jlang:

Without getting too far off topic, is the "find zenphoto/cache" part of the code? Where zenphoto would be my directory?

find zenphoto/cache -type f -atime +90 -size +20 -print

Dreamhost creates a GUI interface so would copy this into the command to run box, set to ??? (how often), use locking, email output to me.

Maybe this will address my "problem" and help determine if it is a problem.

The example jlang gave is not Zenphoto code, that is a direct server command (Perl I would assume) that as nothing to do with it.

Regarding the 200 images, they can come from a slideshow test for example. If you set another size than the gallery image size, it generates cached images, too.

Sorry if there was confusion - the find command above is not not zenphoto, perl or php code - just the unix find command. I run it on the shell command line. No idea how you'd run it in a Dreamhost or control panel type scenario, but a web search brings up examples of php cache-cleaning functions using fileatime().

Ah, right, well, I am Mac user by nature(...:-)), so I try to avoid the shell if possible...:-)

Ah the wrist-slap helped Build 1525 jump menu doesn't have the blank line (changed style from list). So far..... so good.

I'm going to venture one step further on the Album Menu.... if I wanted the URL to go to the page of the GALLERY the album is on and not to the album itself, what triggers this. I don't see what calls the URL to use.

[i]page of the GALLERY the album is on and not to the album itself[/i]
Sorry, I don't get that, the page where the album is is the album itself....

When the choice from the drop down is selected on the Gallery pages, the viewer is taken to the thumbnail page (Album.php) of that album instead of the respective Gallery page (index.php) it is on (I have 1 gallery per page).

That is exactly why and how the album menu was made: to jump directly into an album.

Oh, was hoping it would be more of a "table of contents" for what albums are in the Gallery. Saves having to click every page to see the title and blurb. And, kind of defeats the purpose of the Gallery index pages, I think. Thought it was similar to the pagelist navigation only it tells you where you're going instead of generic "page 1, page 2..."

I didn't put ZP into a subdirectory and can't move until that feature is completed so, it'll do for now