Got the suggestions. Thanks, but...

Well, I gave this a shot... I took the settings down incrementally till I got to 3 and 2. No joy.

I tried this, but I didn't know exactly what I was doing... well, actually I hadn't a clue. I tossed this right under the "global" line where it is pulling in variables (i'm guessing). I did know enough to change the "n" to a value; I chose 60 for the fun of it. Have I mentioned I know no programming and little about web design.

Anyway, no good there either. It still takes 30 seconds and then ends out.

Update on the machine on which this is running. It's not quite as bad as I thought. PIII 733 256MB PC133 memory. Running Ubuntu Linux, no X.

When I click on the generate buttons, the processor utilization jumps to >90%, but I never use up all my memory.

Any other suggestions? I'll let the process run all night if I have to... I just want to get this to generate the thumbs. Let me know if I can post anything else. It's a vanilla install on a clean Linux install too...

Yes, I know they will still need to populate on the page, but it'll be a heck of a lot faster than what I'm seeing now, I'm sure.

after you get the "execution timeout" error, go to your directory and see if any images were actually processed. If there have been no thumbnails, and/or no scaled images created at all, then the issue probably isn't with the script, but more likely with the graphics library or with the images themselves. But I would need more info before I could say that conclusively.

What I can say is this: it doesn't take 30 seconds to resize one image.
What is the average size of your images? ...and does everything else seem to work ok?

WoW, just had a look at some of you pics and I have to say, you do definitely need to use the static image generator--at least for the thumbs.

hopefully you can get me a bit more info (version numbers, etc.) and i'll see what I can do.

I was having the same issue (it seems) as Trinity and Dustin are having. I finally found that although it seemed that GD was installed, it wasn't. Yum'ing php-gd took care of the problem. Good luck guys.

The directories in question would be:

geeklog/plugins/inmemoriam/scaled/
&
geeklog/plugins/inmemoriam/thumbnails/

I have directories called "1" at both of those locations. Both of the "1" directories do have files populated in them, they are quite small in size, so it looks like things are working.

I moved the data out of those directories and tried again to populate the thumbs. It generated 16 files, 5 sets of three and it looked like it started to loop through for a sixth image before it timed out.

Here is the pertinent part of geeklog/plugins/inmemoriam/admin/index.php (I think) to show it should only be looping once.



Version info follows:

Geeklog: 1.3.11sr1
Inmemoriam : Inmemoriam v 0.8.5 plug-in for Geeklog
PHP4-GD: 4.3.10-1
PHP4-imagick was not installed... it is now (0.9.7-1.3)

Need any other versions, let me know.

Thanks!

MrKnisely

lower your numbers as follows:The script should not continue looping thru images after the first one has been processed.

Define "Yum'ing"

Thanks,
-Rob

Yum is the redhat equivalent to apt-get or dpkg.

It's not bad... but it's no apt.

MrKnisely

I set the loop counters both to one and I still time out.

Hmmm...

Any other suggestions?

is that one image at least being processed? anymore than that? If more than one is being process then your script is messed up somehow. If not, then you'll have to get me your GDlib version so that I can check the appropriate save() function. However you probably have 2.x bundled with your PHP 4.3 and so there shouldn't be a problem with that.

If you would rather use ImageMagick, you'll have to wait for my next release as it is not complete in the release you are using.

Yes, it does loop through multiple images until it times out.

I'd be happy to post my index.php... but it's not been edited other than as requested by you here.

Let me ask you this, if it times out does that matter? I mean, if I let it time out and then run it again... over and over again until all the files are done, will it work as it is supposed to?

Point me to a method to get a version of GDlib and it's yours.

Regarding using imagemagick, I wouldn't know the difference if it were staring me in the face. I just want it to work... what's under the hood only matters when the car isn't runnin'.

MrKnisely

yup, it will still work. the processing will begin with the first image it finds that has not yet been processed. so whether it times out or not, the process goes on.

I'm boggled why the loop wouldn't break as it should. I'll have to take a closer look at that function to see where it may have a issue. If I find anything I'll let you know. At least we know that it isn't the image class--that would suck.

Ok, I have a user who is trying to edit an album he created and he keeps getting an SQL error. I checked my error.log and this is what I found:



I know next to nothing about SQL, so I have no idea what this means, any ideas?

there's a comma there that shouldn't be.. gimme a couple secs to look for it.

mrcraig52, and the rest of you who are using 0.8.5, you will all have this same problem so click here to get a new albums.php to be placed in your public_html dir.

mrcraig52, let me know if that fixes your problem. I'm on the wrong machine this weekend to test anything myself.

if you just picked up that file, try it again, the cache didn't refresh when I put up the working file. it's up now though.

If you use the Auto: Scan and Apply button on the Directory Administration page, the folder names that your media is in is used as the album name and ID.

However, if you create a new album yourself, it looks like the ID defaults to the serial number for now()

The reason I was not able to edit my albums was because I used the auto function to create all the albums and the folder names my media was in contained hyphens, which appear to be illegal characters for the ID field.

I would suggest using the serial number for now() rather than the folder names for the album id in the Auto: Scan and Apply function.

Additionally, is there not a way to sort albums in descending order rather than ascending? My album names are dates and I would prefer newer media to appear at the top of the page.

The auto scan doesn't create the album's ID as that simply is a reflection of your directory name. I don't recall having any trouble with hyphens to date, but I will put it on my list and check into it. thanks.
by default, albums summaries on the index page are sorted by date descending, i.e., the date created (not by directory or album names though those names may be in the form of dates). Media thumbs on the browse page are also sorted by date descending, by default. If you've uploaded all your albums via FTP, the script accesses them in the order that they are stored by the filesystem. That order is not controlled by the script..

Hope that helps

That does help. I always work with the media folders in descending order, so I uploaded them to the server in descending order, so that explains it. Thanks for your help. I really appreciate your time.

First off let Me say I LOVE this plugin. Installation went smooth following the docs but I have run into a wall involving the creation of albums/uploading of media.

If I use the interface to create albums, they are created no problem but they are owned by 'apache'. If I then try to upload images to them (still via the interface) the uploads always fail with the following message:



The file size is not an issue but I'm betting that permissions are what's hangin me.

When I use the FTP method of creating and uploading albums/media and then use the scan functions to pull them into the database, everything is golden.

Could this be a SAFE mode issue?

Some stats FYI:

PHP version: 4.3.10
Apache version: Apache/2.0.53
(and sadly) SAFE mode: ON

Any insight/suggestions hugely appreciated.

K

---

It was working... I SWEAR!