Using the Open Source Resource Space DAM (ver 10.1) which incorporates Uppy/tus for the upload protocol. Installation is on a shared Ubuntu server (ver. 22.04.01 LTS), PHP 8.0.29, and MySQL 8.0.33. The internal Installation check reports no issues.
There are very few reported problems in the Resource Space Google Group, leading me to suspect that my server configuration is at issue.
What works consistently:
Uploads of single small (60kb range) files.
What fails:
Single large file uploads (larger than 50 Mb), multiple file uploads including files larger than 60kb. Some files may upload, others fail with possible one file uploading, and 404/subsequent 410 network errors, resulting in this error message:
Sometimes I can attempt an upload retry with limited success with some (not all) queued files.
I have PHP error reporting turned on; none reported. No reported Apache server errors.
The tmp/tus folder will have new exactly 5 Mb files in folders associated with failed uploads. The files seem to be for individual failed file uploads.
The problem exists in Firefox with both Win 11 and Linux PCs. I’ve put the PCs in my router DMZ zone with no change.
Are there php.ini settings that if wrong might cause such issues? If not, what additional information from the failures can I provide to determine where to look for potential solutions?
I am afraid I don’t have a concrete advice for you. The 410 status code is not used directly in the tus protocol, so this is not an indication for a specific problem with resumable uploads. I rather think this is an application-specific error, so it’s best if you read out to the developers behind ResourceSpace directly.
Thanks for the reply, Marius. I know the 410 response is an Apache server code – basically the called URL doesn’t exist or can’t be found.
I’m not a programmer; know HTML/CSS, understand PHP and some Apache. As I read the error message (generated by tus, right?) if I understand what tus does it breaks files down into chunks, keeping track of all the chunks and facilitates uploading them in the proper sequence to the right destination. Somewhere along the way tus (or Uppy?) can’t find the next chuck (URL) and that causes the 410 error. These 410 errors are not reported in the Apache log.
The tus error is part of an Uppy error ("Failed to upload IMG_0714.MOV) with the tus error immediately following. Is this URL error associated with the upload source or destination?
Direct support from Resource Space is unlikely, since they release the program as Open source but also market and sell their services (system hosting, support, etc.) commercially. I could get support on an expensive case basis. No pockets for that! I’m technical enough (spent years in electronics/TV engineering, self taught HTML et al) to do troubleshooting; as I said absent a plethora of similar issues (they do pop up on rare occasions in the forum) I suspect my issues are hosting based, and absent http error in the Apache log my belief is some php.ini setting may be the culprit and or the solution. I have memory_limit pretty high (200M) and post_max_size/upload_max_filesize in the 250M range. Permissions must right, as uploads will sometimes complete.
Is there an available list of recommended php.ini settings I could try for tus or Uppy?
It’s neither. A tus client sends an upload and as tus server handles it immediately. If you need queue you can implement that yourself on the client or use a load balancer in front of the servers.
If you read back through my original posts I’m trying to troubleshoot multiple file upload failures on a shared server. The base platform I’m using has implemented Uppy/tus internally as the upload protocol. The support forum for the platform (Resource Space) has had very few issues with this, which is why I suspect something about the server setup as the issue.
I have no access to the server configuration WRT items like load balancing or queue controls.
This is the Uppy error message I get in Web Developer:
mysite is a pseudonym; Uppy/tus is implemented in upload_batch.php. I’m presuming files/d2b58a68-2336-4444-ad61-b48ac0c4e18c is a temporary structure holding the file to be uploaded.
tus appears to make two upload attempts that both fail. Attempts to upload a large (200MB) file sometimes succeed, sometimes fail with similar error messages.