Is there a way to debug what action is specifically dieing here?
Most likely reconstructing the original file or creating thumbnail / post image.
XFMG video handling is kinda inefficient and you will most certainly run into such issues when dealing with really large videos, especially if using cloud storage (S3, R2, etc.)
\XFMG\Attachment\Media::onAssociation
PHP:
if ($tempMedia->thumbnail_date)
{
$tempThumbPath = $tempMedia->getAbstractedTempThumbnailPath();
$mediaThumbPath = $container->getAbstractedThumbnailPath();
$tempFile = \XF\Util\File::copyAbstractedPathToTempFile($tempThumbPath);
\XF\Util\File::copyFileToAbstractedPath($tempFile, $mediaThumbPath);
$container->fastUpdate('thumbnail_date', $tempMedia->thumbnail_date);
\XF\Util\File::deleteFromAbstractedPath($tempThumbPath);
}
if ($tempMedia->poster_date)
{
$tempPosterPath =...
\XFMG\Attachment\Media::onNewAttachment
PHP:
public function onNewAttachment(Attachment $attachment, \XF\FileWrapper $file)
{
/** @var \XFMG\Service\Media\TempCreator $tempCreator */
$tempCreator = \XF::app()->service('XFMG:Media\TempCreator');
$tempCreator->setAttachment($attachment);
if ($file->getExif())
{
$tempCreator->setExif($file->getExif());
}
$tempCreator->save();
}
When this is called, the attachment upload has been completed, the file has been copied to
data
and the original uploaded...
The whole process of uploading a large video to XFMG in chunks works like this:
- Upload a chunk to the server
- Process the uploaded chunk and store it FlySystem.
If an object stroage is used this includes uploading the chunkd to that storage
- Continue at step 1 if there are further chunks
- Reconstructing the original file by serially reading in all chunks
If an object storage is used this includes serially downloading each chunk
- Feed the original file back to XenForo upload handler
- Process the uploaded original file
If an object storage is used this includes synchronally uploading the original file to that storage
- Creating thumbnail and poster (if enabled)
This is done by copying the whole file from abstracted storage to a temporary local file
If an object storage is used this includes synchronally downloading the original from that storage
- Determining if transcoding is necessary (if not force)
This is done by (yet again) copying the whole file from abstracted storage to a temporary local file
If an object storage is used this includes synchronally downloading the original from that storag
- Queeuing a transcode job (if enabled and necessary or forced)
Steps 1)-3) happen in one request, for large files there will be dozens of such requests.
Steps 4)-9) happen in the request for the last chunk together with steps 1)-3).
Now think about this (assuming FFMPeg and transcoding is enabled):
For a 20 GB file in 100 MB chunks stored in an object storage this means
- ~ 200 GET requests to sequentially download the chunks = 20 GB download in Step 4)
- One POST request for a 20 GB object = 20 GB upload in Step 6)
- One GET request for a 20 GB object = 20 GB download in Step 7)
- Maybe another GET request for a 20 GB object = another 20 GB download in step 8)
Ignoring the overhead for the requests, that's 20-60 GB download + 20 GB upload + processing time.
Even with fullspeed GBit (I'd assume most dedicated servers and VPS don't get more) just the downloads would take well > 2 minutes at least.
Tl;Dr
Without significant changes to XenForo and XFMG it is not really possible to upload videos that large, at least not when using object storage - you might be lucky and it doesn't timeout with fast local (eg. NVME) storage.