A PlayTube upload and FFmpeg troubleshooting workflow

A PlayTube upload can fail before PHP receives the file, during application validation, while a background conversion runs, or when the generated media is served. Starting with the visible error alone often sends debugging to the wrong layer.

Map the upload pipeline

Check the web server body limit, PHP upload and post limits, temporary directory, filesystem ownership, application validation, and available disk space. Confirm the original file reaches the intended location before investigating conversion.

Trace the request before changing limits

Record the test file's size, container, video/audio codecs, duration and filename. Check the browser network response and server access/error logs. A proxy 413, PHP upload error, PlayTube validation message and browser timeout are four different stages. Increasing every limit can create resource risk while leaving the real failure untouched.

• The reverse proxy or web server request limit must accept the complete multipart request.
• post_max_size must exceed the request and upload_max_filesize must accept the file.
• Request and execution timeouts must match whether the application stores or processes synchronously.
• The PHP temporary and application upload locations need free space and correct ownership.
• PlayTube validation must permit the extension, MIME claim, size and account workflow.

After editing PHP configuration, confirm the web SAPI loaded the expected file; a CLI php --ini result may be different. Restart only the necessary service and recheck effective values through a protected diagnostic, then remove that diagnostic.

Verify FFmpeg as the web process sees it

The command working in an administrator shell does not prove the PHP process can execute it. Confirm the configured binary path, process user, permissions, disabled PHP functions, environment, codec support, and the exact command and exit output produced by the application.

Capture the exact conversion boundary

Log a safely escaped command template, input identifier, output identifier, start time, exit status and bounded stderr. Do not log credentials embedded in storage URLs or expose shell commands through a public response. Execute arguments through a safe process API or rigorously escape each argument; never concatenate an uploaded filename into a shell string.

Run the failing command against a copied non-private test file as the same operating-system user used by PHP or the worker. Inspect ffmpeg -version, enabled encoders/decoders and linked libraries. A package may provide FFmpeg while omitting the codec needed by the input or selected output profile.

Probe the input before transcoding

Use ffprobe or an equivalent library to read streams, duration, dimensions, frame rate and rotation. Reject files with no valid media stream or values beyond documented limits. Phone videos often include rotation metadata, variable frame rate or codecs that differ from the filename extension.

Keep the original until the conversion and database update are complete. Write output to a temporary unique path, verify it, then publish it atomically where possible. Concurrent retries must not overwrite another job's partial output.

Follow background state and generated files

Review queue or cron execution, processing flags, thumbnails, output variants, and database status changes. A timeout in the browser does not necessarily mean conversion stopped, while a stale processing state can hide a file that was generated successfully.

Make the media job restartable

A conversion job should claim one media record atomically, increment an attempt counter and record a lease or start time. If the worker dies, an expired lease can be retried. Before retrying, inspect or remove only that job's temporary outputs. Mark success after required outputs exist and have passed validation.

Separate permanent input failures from transient worker failures. An unsupported or corrupt file should become rejected with a useful private reason. A full disk, temporary storage outage or killed worker may be retryable with backoff. Infinite immediate retries can exhaust the server.

Control resource use

Video conversion is CPU, memory, disk and I/O intensive. Limit concurrent workers based on measured server capacity. Reserve disk for originals, temporary data and final renditions, and alert before it is full. Apply per-job time and output limits so a pathological input cannot occupy a worker indefinitely.

If the site shares a small server with PHP and MySQL, unrestricted FFmpeg processes can make ordinary page requests appear broken. Use priorities, worker queues or separate media compute when volume justifies it. Measure processing duration and queue age rather than guessing concurrency.

Test delivery after processing

Validate MIME types, byte-range responses, storage or CDN paths, and playback on mobile as well as desktop. Retain useful conversion logs privately and remove abandoned temporary files through a bounded cleanup process.

From file existence to playable media

Confirm the generated file has expected audio/video streams and duration. Request it through the same public route or CDN used by viewers. Video players commonly depend on byte-range support, correct content length and a suitable content type. A file that plays from the server filesystem may still fail through an incorrect proxy or storage header.

For HLS, verify the manifest and every segment path, permissions, MIME type and cache behavior. Avoid caching a transient failure for a long period. When using remote object storage, ensure the application writes the final key consistently and that any signed access lasts long enough for the player workflow.

A bounded diagnostic sequence

1. Upload a small known-good reference file and identify the first failing stage.
2. Confirm effective server and PHP limits without increasing unrelated settings.
3. Verify the stored input and its database record.
4. Run the exact FFmpeg path and arguments as the worker user.
5. Inspect exit status, stderr, temporary output and available resources.
6. Follow the job state through thumbnail and rendition generation.
7. Request the final asset through its real delivery path on desktop and mobile.
8. Retest a large valid file, an invalid file and an interrupted worker.

A reliable repair identifies which layer failed and leaves that layer observable. It avoids the common pattern of raising global limits, granting broad permissions and waiting for the same problem to return with a larger file.