[Solved]: Problem with Batch Add Files Function

[baysidemk]

I hope I am getting this right this time.    I read through the "upload troubleshooting" section.  

I set all the permissions in all the files and folders in the cpg14x directory to 777 to eliminate permissions as a potential problem.  

I edited the limits in the php.ini file to raise the memory limit to 64mb and the execution time settings to the following:
max_execution_time = 600    ; Maximum execution time of each script, in seconds
max_input_time = 600    ; Maximum amount of time each script may spend parsing request data
memory_limit = 64M      ; Maximum amount of memory a script may consume (64MB)

Upload file maxsize is set to 25M and PHP file uploads are on - verified this with the php info button on the cpg page.  Have debug on and seeing no obvious error messages.

I am running the Joomla Bridge. And, I upgraded to 1.4.25.

What is happening is that I go to the batch add files tab.  I select a directory (e.g., "2009_Mothers_Day_JPGs/".  i then click OK.  The next page that comes up lists the files but it has broken icons in most of the right column where the thumbnails ought to be.  If i click on the file names, it opens a window with the full size picture and those all seem to be fine.  Only 10 out of 170 of the thumbnails populate correctly and those are the only ones that get added to the specified album when i click the insert selected button.

The site is at http://nyckatz.com/site and there is a test id **** with pw **** that has super admin priveleges.  need to login on the joomla homepage at this address and then a second tab will appear with the coppermine bridged content

**** Removed admin password

[phill104]

Never post an admin account online. I have removed the details. Please remove that account and post a standard account on here for us to look into your problems.

Read the following from the docs doing everything outlined therin.

http://coppermine-gallery.net/demo/cpg14x/docs/index.htm#upload_trouble

[baysidemk]

Thanks for the reply.  I downgraded the account to a standard account (registered).  User is t3st and pw test4321. However, the batch add function and the whole administrative tab strip with config, etc. will not display when logged in to a standard account so I am not sure how you can reproduce the issue with this account.

I checked the reference you cite and I believe I have done what you suggested.  The one parameter I could not find was LimitRequestBody.  It does not appear in my php.ini file.  Not clear if this could be an issue as I am batch-adding files already uploaded via FTP.

Also noticed one other thing -- if i click on the broken thumbnail images on the right, it pops up a window showing the full size image (similar to what happens when i click on the file name) so it appears that the thumbnail creation process might be dying.  I saw one post about thumbnail problems that said to set the graphics library to GD2-- mine was already set to gd2 and the PHP info screen says GD support is enabled with bundled version 2.0.28.

[Joachim Müller]

I have created a lengthy reply while I was at home, but when I tried to submit it the support board was down so I couldn't. I'll post my reply today in the evening when I get home. Please stand by.

[Joachim Müller]

that has super admin priveleges

Yikes! Do you want to see your site hacked? That's of course totally silly to post an admin account on a public forum. I edited out your posting accordingly and changed the password for that account.
The docs ask for a non-admin test user account.

I read through the "upload troubleshooting" section.

No, you have not, or at least you haven't read on to the section named "asking for support on upload issues" although you should have read that and you should have done as suggested there: I have tried http uploads first, but the admin account you posted didn't even have permission for that. I assigned permissions accordingly and tested http uploads with a know-good file, which worked as expected (see http://nyckatz.com/site/cpg14x/displayimage.php?pos=-158 - you
can savely delete that).

I edited the limits in the php.ini file to raise the memory limit to
64mb and the execution time settings to the following:
max_execution_time = 600    ; Maximum execution time of each script, in seconds
max_input_time = 600    ; Maximum amount of time each script may spend
parsing request data
memory_limit = 64M      ; Maximum amount of memory a script may consume (64MB)

According to http://nyckatz.com/site/cpg14x/phpinfo.php :

max_execution_time = 180    ;
max_input_time = 180    ;
memory_limit = 64M      ;

I select a directory (e.g., "2009_Mothers_Day_JPGs/".

Not a bright idea to name your folders that way. Capitalization matters, and it's recommended to use lower-case.

The next page that comes up lists the files but it has broken icons in most of the right column where the thumbnails ought to be

That's not surprising at all: the images have such a high resolution that it's ridiculous to think that a webserver could or should cope with resizing hundreds of them. I picked one random example: http://nyckatz.com/site/cpg14x/albums/2009_Mothers_Day_JPGs/2009_05_10_0480.JPG is 3.744 x 5.616 pixels (although comparatively small in file size with only 1.4 MB). First of all, the extension is bad: as suggested, you should use all lowercase. Second, the image will consume a lot of memory: according to the forumula to be found in http://coppermine-gallery.net/demo/cpg14x/docs/index.htm#ErrorAllowedMemorySize the memory consumption is roughly (3744 x 5616 x 3) / 1048576 = 60 MB.
Now that's the size in memory for one image, but on that page you have plenty of them, so you will reach your 64 MB limit in no time, nearly with one pic.

The problem lies in the super resolutions that modern cameras can create - they are just silly and not necessary. If you can, reduce the quality in your camera. Alternatively, resize the pics on your client before uploading them, as suggested in the tutorial
"Batch-resize pics".

You have caused a lot of effort for me: answering your question and setting things right took me rather long. Reason is: you haven't made thorough preparations for your posting, i.e. you haven't made your homeworks. Do so in the future please - my time as a supporter is readily spent, but I want to have the impression that people at least try before asking.

[baysidemk]

I appreciate the effort you have put into your response.  I just wanted to let you know that I have found a solution, although it meant switching to an another application for photo sharing. 

I downloaded and installed that application and encountered a similar problem with the thumbnail process failing on the same pictures.  When I searched the support forum for that application, it suggested switching the graphics toolkit to NetPBM instead of GD.

With NetPBM instead of GD as the graphics plugin, the process went through with no problem, with all of the hi-res pictures.  It took a minute or so, but the albums are showing correctly.

I suspect if Coppermine were to use NetPBM, it could also ingest mass quantities of hi-res pictures without encountering this sort of issue.

I am posting this in the interests of being constructive.  I hope it is taken in that spirit.

[phill104]

Good luck with your site. It is a shame you did not stick with coppermine.

It is also a shame that you did not listen or maybe did not understand what he is on about.

Uploading big images like that will result in trouble for you whatever image manipulation software you use. Here are some reasons, there are many more.

• Uploading large images eats a lot of bandwidth and takes a long time even on a fast connection
• Once those images are uploaded your server will be under a lot of load manipulating them whether you used GD, Imagemagik (also supported by coppermine) or NetPBM, your host may even warn you or restrict you
• Your server space will very quickly be eaten up by all those massive files
• The end user may struggle to view them as they are huge
• Viewing those big files on a slow connection will be very hard indeed
• High res images are often stolen and end up on library sites etc but lower quality ones are just not worth it.

As I said, this is far from a comprehensive list as to why you should not upload such large files. A far better way is to batch resize them before upload as suggested above. There are plenty of free tools for doing this. There is even a plugin (Jupload) that can do this for you as well as upload lots of shots for you in a nice easy way.

Whatever photo software you end up using, bear these points in mind. It will make your life easier in the long run.

[Joachim Müller]

Thanks for returning and posting your solution. We don't bear a grudge against our "competitors", and it's perfectly OK to mention the name of the app you ended up using as well, for the benefit of others with similar issues. The app in question probably is Menalto Gallery.
Using another library than GD2 will be a relief in resources consumption, but not a dramatic one, so your might end up in your webhost waggling the no-no finger at you if you continue processing those incredibly large files (Phill explained this already in detail).