I have a lot of canon raw (CR2) photos. They live on an nfs attached NAS device. When page through my albums, the first time takes a long time - 30 minutes is not unusual. I have selected the option to use the 1st alphabetical entry in albums for the thumb. Having a look at the code it seems that it do the cr2->png conversion for the thumb on every picture in the album before it decides it only wants the first one. This is done be the call to getImages in getAlbumThumbImage. Also it doesn't seem to cache the results, so visiting the album causes the thumbnails to be generated again.

What are you using for support for CR2 files? Not something that Zenphoto does native.

Imagemagick - i thought that was supported by zenphoto

Lib_imagick is supported. I do not have Imagemagic and was not aware it provided support for raw files.

I am not sure I understand what you are saying, though. getImages() simply returns a list of filenames. It does no image processing.

getAlbumThumbImage() does instantiate the image to see if it is a "photo" but it does not attempt to do any image processing. It also "stops looking" as soon as it finds a suitable thumbnail. Conversion happens only when the browser attempts to view the image and is done through the i.php script. If the i.php processes the image is it is also cached. There is never any in-line image processing done by Zenphoto.

I've added a few debugLogs to see where the time goes. In getAlbumThumbImage it calls getImages.
Here it loops through the images "foreach ($images as $filename)" line 488-ish (adding the deubLogs will have slightly changed the line number)

This calls newImage which in turn calls "New _Image" this calls: parent:ersistentObject. This call takes 15-30s typically for a CR2.
Later the block "if ($new) {} " also takes 15-30s to execute, though I haven't figured out which of the calls is taking up the time yet. While this is going on the are file related files in /tmp being used, typically a .png file is present amongst the temp files.

Zenphoto does not directly use the /tmp folder, but perhaps something downstream does. We look forward to your analysis. It might be interesting to see what the same results are for jpg or png files.

You should not be in the if ($new) { unless this is the first time the image has been seen. But if you are there, one thing that might be taking the time is the metadata processing.

I imagine is it imagemagick that is using /tmp.

Clearly it is the meta processing. I've basically uploaded a large number of directories and files. The qn is why does it do it when all it needs to do is get a list of files - which is what you implied above.

As I said above when it's finished the only thumbnail it retains is the one it has chosen to represent the album. So when one visits the album for the first time one still has to create the thumbnails for all the pictures in the album.

It instantiates the image to be able to test the "kind" of image. For instance, if it were a video it would not be used for a thumbnail unless it has an alternate thumb image.

But the metadata processing should happen only one time. Once the image is logged into the database it is no longer "new" unless its filemtime changes.

Also the loop terminates when a suitable thumbnail is discovered. Retaining the thumbnail image in the cache is quite different from selecting an image to be the thumbnail.

I have looked at the lib_Imagick code involved in metadata handling. It would appear it does make a png file when it is extracting IPTC data. So this is probably where the /tmp files are coming from.

Does it need the IPTC data at that point? Can you make it "lazy" - that is don't read it till you need it?

The 'problem' - well I think it's a problem - seems to come from the call to getImages(0,0...) that according to the documentation will mean it will read every file in the directory and doing the IPTC thing. As I don't really care what picture it defaults to I changed it to getImages(1,1...) which I think will mean it will only return one. This should make the whole thing workable. That is not a good general solution though. A good solution might be to pass a max count to getImages.

I will repeat again: Only "New" images will have their metadata processed. New is defined as not seen before by Zenphoto or having their timestamp changed from when Zenphoto saw them.

The database needs to be populated with all the image data when the image is discovered. Otherwise there is no reasonable point in time that could be used to do that. But since this is a one-time occurance that should not present a problem. For instance if you have selected one of these fields as your image sorting key then the sort will be wrong if the field is not populated.

You do not correctly interpret the parameters to getImages() that first parameter is the page number for which images will be returned, not the number of images. Even if you do pass "1" as a parameter it is still necessary to enumerate the images as othewise there is no way of knowing which images belong to page 1.

Maybe you should manually select the image for the thumbnail?