EDIT

The webservice for fetching the media metadata (metadata + link to file) is very fast, so these service calls are not critical (though they could maybe be done within one call and not with separate calls).

E.g. https://int.e-taxonomy.eu/cdmserver/integration_cichorieae/media/2e88b394-b851-4b16-88e6-fe7d90c22e5d.json

Media handling during the simple search is a little bit strange, in a first step the method _load_media_for_taxon() is called, which gets all media defined in portal settings (from accepted, specimen etc)
In a second step for every of these media a ws to get the complete media object is called.
Maybe we should think about to merge these two steps? Or the first step should only return a list of uuids.

The algorithm to get the best matching representation of a file seems to be not deterministic. Running the search several times, returns different representations of the image.

Here the problem was, that the images weren't available anymore. I adapted the uris and now the search is much faster.

But why does a not existing image make the loading slow? Can't we improve this. In theory a missing image should be faster as there are no data to load.

Katja Luther wrote in #note-15:

The algorithm to get the best matching representation of a file seems to be not deterministic. Running the search several times, returns different representations of the image.

Can you leave a note where to find this alogithm?

Andreas Müller wrote in #note-18:

Katja Luther wrote in #note-15:

The algorithm to get the best matching representation of a file seems to be not deterministic. Running the search several times, returns different representations of the image.

Can you leave a note where to find this alogithm?

filterAndOrderMediaRepresentations in MediaUtils, called by findPreferredMedia contained also in MediaUtils ...

Short summary of what is done:

• Depending on the rules in the preferences temporary representations are created
• these representations are filtered by mimetype and sorted by distance to the requested size or height/width

Andreas Müller wrote in #note-17:

Here the problem was, that the images weren't available anymore. I adapted the uris and now the search is much faster.

But why does a not existing image make the loading slow? Can't we improve this. In theory a missing image should be faster as there are no data to load.

But this is a problem of the server containing the image, isn't it?