I have same issue – we are dealing with this error after updating to v6.2. If I upload single image, it is fine, but when I upload multiple images, some of images failed and no scale images are generated.
Thank you for reporting this, I’ll have to find some time to try it out with WP v6.2.
I just tried to import 3259 images in WordPress 6.2 (PHP 7.2.34) on an actual (cheap/basic) server, so not locally β and it worked fine. The only issue I found was that it stopped roughly mid-way when my computer went to sleep (because it was taking so long). But then I just ran import again and it continued where it left off. I imagine that a similar thing could happen if your WP login session expires.
—
When reloading the page I see, that itβs doing more in the background.
Those might be some other requests, but this plugin just doesn’t do anything after page is reloaded.
Looking at the Firefox Debug Tool itβs exectly that: The last XHR request doesnβt have any response data.
I was able to get this empty response error when my computer went to sleep (as I explained above).
So I’d suggest trying to:
- prevent your computer from going to sleep or losing internet connection,
- keep WordPress logged-in session active (maybe opening WP in a new tab and reloading there), but definitely do not reload the tab where import is happening (this would stop everything),
- trying again if it stops.
Thanks a lot for the suggestions, but it’s definitely not a problem of the client side. It’s about importing around 20 to 40 images, so in whole about 1 to 2 minutes β nothing that leads to a sleep, loosing internet connection or a session timeout.
As I reported above, raising the max_execution_time in php.ini solves the issue. So my guess is:
The algorithm tries to import 5 images at a time. As WordPress generates different image sizes, it tooks sometimes more than 30 seconds (standard max_execution_time) to finish these 5 images (more than 6s/image in average). If this will happen, the server aborts execution and no response is send to the client. Because there is no response, the javascript won’t go on with the next images.
To dig a little bit deeper: In my instance WordPress will generate 5 scaled versions of an image. As the server is optimized to reach out static content (cache system), resizing images is not the fastest process. So generating 5 scaled version of a large image may be longer than 1 sec per scaling and we hit the 6 sec per image limit easily.
A possible solution on the server side (as I said above): After processing 1 image (of 5) just call set_time_limit(). This will reset the execution time and the script has again 30 seconds to process the next image. I did not read the source code of Media Sync, so maybe this is already done; in this case it needs futher fine tuning.
Best and thanks,
Jan
Interesting, thanks for the details! What I could do fairly quickly is to make this “batch size” customizable (for any number of selected files). Currently, it’s:
10 (files per request) when importing more than 100 files,
5 for more than 10 files,
1 for up to 10 files.
I mean, to me it doesn’t seem like a good idea to set it to 1 when importing a lot of files since that would make a network request for each file and would take forever. But it might be necessary in some cases, so I’ll try to do it tonight or at some point this week.
@g4rf @smook02 I just pushed new version (1.3.0) which allows setting custom Batch Size. So even if importing thousands of files, you can set Batch Size to 1, 2, etc and hopefully your issues will be solved. It will just take a while π
Please let me know if it helped or if you have other ideas how to solve it.
Thanks
Thanks for the code update, I’ll check this today or tomorrow. I think, that this will solve the issue, even if the whole process will last longer because of more network requests.
I’ll checked your code now and my idea was this one:
In your MediaSync.class.php in line 813 there is the call to the WordPress core function wp_insert_attachment(). This call may last too long per image so that with 5 images the whole script execution time hits max_execution_time in php.ini. If you now add a call to set_time_limit() before the wp_insert_attachment() call (and so reset the execution time), then every wp_insert_attachment() has (in standard confs) 30s to execute. That should be long enough for one image.
With this solution you won’t need too reduce the batch size, as long as one call to wp_insert_attachment() is faster than 30s. You can theoretically even raise the batch size to 100 or 1.000 β but this will lead to long lasting http requests, but never hit the max_execution_time.
Best, Jan
Thanks for checking it out, sounds like it can work. I’ll just have to find some time again to try it out and implement it.
Hey @g4rf, I just pushed your suggestion to the current v1.3.1 (since it’s a smaller change). Though it might have a big impact, let’s see π
If this solves your issue, could you please resolve this topic?
Thanks again for great suggestions π
Hi @erolsk8,
I checked it now with a new bunch of 72 files (7 videos and 65 images). It worked, but not completely. π
I tried it 3 times and the progress bar stopped around 30 imported files. For the last import I let it go (doing some other work) and as I tried just again to import the other half, it said that already everything is imported.
Also it didn’t show 10 images in every batch round: It started with 10, than it showed e.g. 19, than e.g. 27 β it seems not to have a pattern in it.
So: The progress bar stopped viewing the results, but the files were imported properly.
Some remarks:
- I didn’t find the set_time_limit in your code. Did you do something else (apart from the manual batch size setting)?
- I guess, that there is β beside of the max_execution_time on my server β another issue with displaying the correct number of imported files. But that is just a guess and I didn’t dig deeper into it.
So far I think with the manual batch setting the issue is solved. If there are any display errors while counting, than I have no clue, where to start.
Thanks for debugging this issue! π
-
This reply was modified 3 years ago by
garfield.
Oh, that’s some strange behaviour. But if you don’t see set_time_limit in code, it could be that you already had version 1.3.1 before I pushed this “set_time_limit” change (to the same 1.3.1 version). I added it just before the wp_insert_attachment like this:
$max_execution_time = ini_get('max_execution_time');
if ($max_execution_time) {
// Reset execution time so that each file can be processed
set_time_limit($max_execution_time);
}
$attach_id = wp_insert_attachment($attachment, $absolute_path);
In any case, I’m glad it’s kind of solved π
Thanks again for the very useful feedback.
It seems this error is related to a wordpress bug: https://core.trac.ww.wp.xz.cn/ticket/58202
Oh wow, thanks for sharing @septemberdigital!
That reminded me of this message from some other reported issue here: https://ww.wp.xz.cn/support/topic/media-synk-error-e/#post-13184876
Hi. I solved by replacing the extension imagick with gmagick, on php 7.4.
On other installations with previous versions of php (like 7.2), imagick works fine, but still, in case, you could try gmagick anyway.
bredchic