Jump to content

FileUpload stops at 100%

iNoize

By iNoize,
in General Support

 Share

Recommended Posts

iNoize Sr. Member

iNoize

Posted
Posted

Hello, 

i have some problems with the file upload. 

On my own Internet connection it works pretty fine. 

The customer had an slowly internet conection so it takes several minutes to uplad an 5MB file. 

At 100% stop it and dont really upload. 

Is there a way to upload the files simpler in the backend for the customer with the slowly connection ? 

What could be the reason ? 

Tnx 

Link to comment
Share on other sites
LostKobrakai Hero Member

LostKobrakai

Posted
Posted

You can hardly change the internet connection of your customer, so your options are only those two:

- Up the max_execution_time of php, so it's long enough to receive the full files.

- Use every possibility to get the image smaller on the customers side before the upload.

Link to comment
Share on other sites
LostKobrakai Hero Member

LostKobrakai

Posted
Posted

Opera turbo only improves download and not uploads. Uploads would only get slower.

internet -> big data / fast -> opera (improvements) -> smaller data / slow -> client

client -> big data / slow -> opera (improvements) -> smaller data / fast -> internet

client -> big data / slow -> internet

Link to comment
Share on other sites
iNoize Sr. Member

iNoize

Posted
  • Author
Posted

So there is no way to fix it ? 

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator,
service@webmailer.de and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.</p>
<p>More information about this error may be available
in the server error log.</p>
</body></html>
 
Thats the error that the user gets or if I try to upload with smaller connection. 
Link to comment
Share on other sites
rick Hero Member

rick

Posted
Posted

Hi iNoize,

I'm just trying to get a better understanding of what is going on here, so please don't take offence to my questions. :)

Usually a 500 error is some mistake made in programming or configuration, such as an error in an htaccess file, and it is rarely (in my experience) an issue with a process, like uploading a file.

Is your web server running IIS or apache or ??

Are there any entries in the web server logs corresponding to the approximate time the error occurs?

I see the domain is webmailer, is the file upload processed as an attachment? Is the file upload in any way associated with a mail server?

When you state the upload stops at 100%, is that based off the browser progress indication, or on an upload progress indicator function defined in your application?

Have you increased the settings for memory use, timeout, upload file size, and retried the upload?

Is it one specific file only that your user has an issue with, or does it affect every file regardless of file type or size?

Is the PDF file being uploaded created by that user, or is it an existing PDF file, such as a form, that they have saved and want to upload?

Since this issue is with one of your users, have them send you their IP so you can easily locate their connection data in the log files.

Link to comment
Share on other sites
iNoize Sr. Member

iNoize

Posted
  • Author
Posted

Ok thats really from customars site problem, 

I cant reproduce this error. 

tried to upload 80MB Files and it worked. 

I think about to use this one  https://processwire.com/talk/topic/6377-fieldtypeselectfile-inputfieldselectfile/ 

for the customer. 

Is there maybe an module where i can handle like input field file ? 

Here i can only select the files and output the names. no description or something like this. 

Link to comment
Share on other sites
  • 1 year later...
alan Hero Member

alan

Posted
Posted (edited)

I've hit this a number of times and it's one of the very few things that makes me uneasy in the PW world.

Why? Because in the past I've felt like I just threw resources at PHP until the problem went away and the step change I had to make in settings always seemed both illogically large and also so big as to make me worry it might mean I am impacting the operation of the site (or other sites when shared hosting).

So when a site recently hit this problem I tried a little more to see where the limits were and see if I really had to be so disproportionately generous with resource settings before getting it to work. It seemed so ?:/

Essentially I have some clients who often want to host files of 100mb, 200mb, etc size. I know I should explore using some other space for heavy lifting of files and perhaps thats THE problem, but I would love to know (is using the PW Admin to upload files of 150mb, 200mb, 250mb unreasonable and it's always going to be an uphill struggle?).

For example, a 166mb file. After making various php changes that I completely understand such as 

post_max_size from 16M to 200M
upload_max_filesize from 20M to 200M
memory_limit from 128M to 200M
max_input_time going from 60 to 180
max_execution_time from 30 to 180

Essentially it looks like I need to move from these settings that make sense to 

memory_limit 655M

before a file load would 'complete'* (memory_limit at 647m or less still fails).

*When it works, at 655m, what actually happens is the load bar reaches 100% and the activity GIF rotating on the LH side stays visible, never disappearing and the File Description field never appears—unless I click Save, once I click save then, with the 655m setting, I'm all good and the upload is complete and the File Description field is visible - twice now it HAS completed AOK (the GIF disappearing and the 'Description' box appearing aok), it looks like I just need to leave the page longer, not timed it as both times it's happened when I've gone off to do something else. Will post a reply if/when I find more in case helps anyone.

PW is 2.7.3.

I'm posting this as much to document it as seeking answers, but I would love to know why I appear to need such a disproportionately large jump in settings to allow larger files. For example, I had the exact same error when using a 256mb file and to get its upload to 'complete'* (*all good but need to click save to loose the GIF) I needed to set memory_limit to 850. Seems a lot and I don't understand why...

Hope this helps someone, if I find more I'll post here (though I spent a couple of hours+ already experimenting & think I am running out of ideas ATM).

Edited by alan
Crossed out items and correction after 1st of those.
Link to comment
Share on other sites
LostKobrakai Hero Member

LostKobrakai

Posted
Posted
14 hours ago, alan said:

but I would love to know why I appear to need such a disproportionately large jump in settings to allow larger files.

The size you're seeing is most often the size of the image in a compressed filetype (essentially everything except uncompressed .tif). For resizing those images do need to be fully load in memory, which means the image is being uncompressed and therefore it's quite a bit larger. But in case of such big images it might be better to change the workflow. Even just uploading files of such a size via a simple html form is bound to be error prone (timeouts, network or memory issues). 

  • Like 3
Link to comment
Share on other sites
szabesz Hero Member

szabesz

Posted
Posted
1 hour ago, LostKobrakai said:

it might be better to change the workflow

For example: clients could ftp the images and the site can "auto detect" them. Clients need to be educated of course in this case, so this is a serious drawback of this solution... but it might work, depending on the client.

  • Like 1
Link to comment
Share on other sites
BitPoet Hero Member

BitPoet

Posted
Posted

@alan: are you talking about images or files, which are two different beasts in PW? For regular files, your memory requirement seems too high, but for images @LostKobrakai's recommendation applies. If we're in fact talking images, you might try a more recent PW version (as far as I remember, there was a fix after 2.7.3 came out that removes in-memory copies earlier when resizing images) and/or have a look at ImageSizerEngineIMagick. Also, if you have $config->debug set to true, it might be worth checking if the memory requirement changes when you disable it.

  • Like 1
Link to comment
Share on other sites
alan Hero Member

alan

Posted
Posted

Thanks all.

I should have said, these are invariably .mp3 files.

I'm (slightly) stuck re the PW version as I am using @kongondo's brilliant Blog module which when I developed the site was not spec'd to run on v3 PW.

I will return to this issue since I want to solve it (and understand it), but for now my two workarounds have been; upping the memory enough so the upload completes (albeit seems too high a limit) and the other solution that seems to work is the client uploads a small file, I FTP the large version over the top—not ideal but in this case very workable.

I am sure using a form to upload a large file is not the best choice going forward, for very large files. If I had time I'd love to see if I could spec' out a sort of 'lazy upload' module for PW; making this up as I type, but perhaps something like a GUI to identify the upload and 'register' it to happen and a one-time cron-type job that grabs the file from perhaps a Dropbox or Google Drive like location.

PS: Although I said

Quote

what actually happens is the load bar reaches 100% and the activity GIF rotating on the LH side stays visible, never disappearing

I am pretty certain that on one of my tests I had to leave the screen for 20 minutes and when I came back it HAD completed, w/o needing a save to make the GIF disappearing process complete... I will test this again.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...