This section describes known issues found by the ImageVault team.
Some LINQ queries throws InvalidQueryException
In some cases a LINQ query throws InvalidQueryExceptions when it detects a possibly bad performance query. The main purpose is to indicate limitations in the LINQ query provider and force the developer to rewrite the query.
Media thumbnails is not visible after upload if running as a subsite of Episerver and using proxy providers
Fixed in ImageVault v5.5.
This issue only occurs if you have not specified serviceUri of the proxy membership/role providers.
Setting EPiServer property to required doesn't render correctly first time after site restart
Fixed in ImageVault.EPiServer.UI v5.4.
If you have a MediaReference or a MediaReferenceList property and are setting it to required, the first time after a site has restarted, the editor isn't rendered at all. The behavior is described in a forum post on world.episerver.com and is registered as a bug in Episerver.
Entity Framework sometimes causes transaction deadlocks
The ImageVault core service uses Entity Framework to handle most of its database reads and writes. The Entity Framework, however, contains a bug related to concurrency version checks that can cause transaction deadlocks. The bug has been confirmed by Microsoft and they have release a hotfix as a remedy.
If you experience long delays and/or errors when saving organized media in ImageVault you can avoid this by:
- Installing the hotfix supplied by Microsoft on the server(s) hosting the ImageVault core service. Be sure to follow their installation instructions to avoid issues related to the install.
Bad Request when uploading media
If uploading media using the ImageVault UI fails and upon analyzing the underlying error it presents the message
The remote server returned an unexpected response: (400) Bad Request.
This error can indicate that the authentication ticket is too big for the HTTP header field. The ticket gets large when a user is member of many groups or if the group names are very large. A workaround is to use user that isn't member of a great number of groups (less than 20) or a role provider that filters out some of the groups.
Note: This is fixed in ImageVault 4.2. If you perform authentication manually without using any ImageVault components, make sure to use the new authentication method that utilizes the registerTicket call.
Installation - Fail to acquire a security provider from the issuer's certificate
This can occur when the installation tries to create a certificate. The cause is often that private key of the certificate used to issue the certificate is unaccessible.
To solve this, remove the ImageVault Default Root CA certificate from the LocalMachine/Trusted root certificate store and rerun the installation. The installation will install the issuing certificate if missing.
Only do this if you know what you are doing. Removing a trusted root certificate can result in side effects.
Multiple ImageVault UI sites on the same domain(site) (IV <= v4.3)
If multiple ImageVault UI sites that uses different Idp:s there will be problems regarding the authentication ticket. The UI uses a cookie for storing the ticket after authentication. If multiple ImageVault UI sites (or other sites that uses passive cookie based federated authentication) resides on the same site (same web domain address) these cookies can collide since the name and domain is the same. The solution is to change the name of the cookie so that they don't collide.
Changing the name of the authentication ticket is done in web.config for the ImageVault UI site by changing the following value. Just make sure that the cookie name is an unique name on the domain.
Windows authentication gives access denied (401.1)
If you have installed a local site that uses a mapping to the localhost name (using the hosts file for example) and are using windows authentication you might experience access denied when trying to login to the website. This is not a Epi/ImageVault problem, its windows/IIS specific. See more information and solution at MSDN.
How to remove failed upload media
Sometimes a file can be damaged or the storage plug-in system is not responding and the file get caught in the file upload queue. Files in the queue will be retried multiple times and if you want to remove them, permanent or temporarily, follow the following instructions
How to force reconversion of converted media
This is an instruction on how you can force a reconversion for a converted media, like if a conversion is flawed and a newer version has supplied a fix for that type of conversion; or if support for a new conversion is added and you need to clear the old conversions. Read the How to force reconversion of converted media walkthrough.
MediaConversions does not come in the same order as formats requested
If you request, using the API, multiple conversions at the same request, by supplying a list of formats, the resulting MediaConversion property on each MediaItem is not guaranteed to contain all requested formats and not in the same order as the supplied list.
This is fixed from version 4.4.20 and the consequences of that fix can be read in detail in the MediaConversions can contain null values article.
401 when accessing internal media
If using a mismatch of versions for core (v4.5.10 or later) and client you might get this problem.
Slow conversions for large Jpeg images
In some cases, conversion of large jpeg images are slow when using the LeadtoolsConverter. From version 5.2 a workaround exists where you can add the DotNetJpegConverter with a greater priority than the LeadtoolsConverter to force jpeg conversions to use this converter instead. To activate it, add the following converter to the