TYPO3 Core

The example image uses storage 1, there are other images with same filename and same content with storage 0 (but not uid 7356).
There are also two languages on the website.

Maybe these facts are related to the issue, that the checksum is available in two variants. Unfortunately I cannot reproduce the problem properly but it occurs several times a day - error logfile with images not available is a good ressource.

Regards,
Karin

Hi Karin,

don't know if the empty columns in sys_file_processed table may cause problems.

But a question to your getChecksumData() array given above. Is this the result of AbstractGraphicalTask::getChecksumData() or AbstractTask::getChecksumData().

If this is the result of AbstractGraphicalTask::getChecksumData() it is a) impossible that you get different md5 hashes b) I'm missing a fourth array element.
So I guess this is the output of AbstractTask::getChecksumData().

Hi Markus,

sorry forgot to mention, output is from AbstractTask::getChecksumData() which generates the filename of the processed images as far as I noticed.

Ok, but the checksum is calculated from the output of AbstractGraphicalTask::getChecksumData(), which adds the serialized $GLOBAL['TYPO3_CONF_VARS']['GFX'] array to the array returned by AbstractTask::getChecksumData().

So the only reason why the hash changes is, that $GLOBAL['TYPO3_CONF_VARS']['GFX'] changes, maybe try to debug why that happens.

Thanks a lot for the helpful hint.
The behaviour occurs if a GFX setting is defined more than once with different values, e.g. in LocalConfiguration (where it should be) and overwritten in another individual extension.
Topic can be closed please.

Interesting. The question arises why those settings from the extension are not always applied?

Hi,

image checksum problems only occured where this individual extension was involved.
Difference was in jpg_quality setting:

"jpg_quality";i:100 (set in extension)
"jpg_quality";s:2:"85" (set in localconfiguration via install tool)

I cannot reproduce when exactly it occured. I discovered it mostly as soon as editors made changes, while switching languages or generating pages uncached with no_cache parameter - but only sometimes. So something related with caching - maybe sometimes the ext_tables of the extension was loaded before localconfiguration and sometimes afterwards - for whatever reason? Unfortunately I know not much about core functionality in detail.

Regards,
Karin

LocoalConfiguration is always loaded first.

Is this configuration overwritten in ext_tables or ext_localconf? I would suggest to put this inline into ext_localconf.

Configuration was in ext_tables but in fact it is not necessary. I just took over the website and removed it now.
I also tested to put it in ext_localconf and did not discover any problems - the overwriting configuration of ext_localconf was taken in all cases. Thanks for your help.