1
votes

I am on v8.2

I see the following error in the log file:

 ERROR Could not run the 'getMediaStream' pipeline for '/sitecore/media library/test image'. 
Original media data will be used.
Exception: System.ArgumentException
Message: Empty strings are not allowed.
Parameter name: filePathOrExtension
Source: Sitecore.Kernel
   at Sitecore.Diagnostics.Assert.ArgumentNotNullOrEmpty(String argument, String argumentName)
   at Sitecore.Resources.Media.MediaThumbnailGenerator.GetThumbnailFileName(MediaData mediaData, TransformationOptions options)
   at Sitecore.Resources.Media.MediaThumbnailGenerator.GetStream(MediaData mediaData, TransformationOptions options)
   at Sitecore.Resources.Media.MediaData.GetThumbnailStream(TransformationOptions options)
   at Sitecore.Resources.Media.ThumbnailProcessor.Process(GetMediaStreamPipelineArgs args)
   at (Object , Object[] )
   at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args)
   at Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, String pipelineDomain)
   at Sitecore.Resources.Media.Media.GetStreamFromPipeline(MediaOptions options, Boolean& canBeCached)

I guess it is because of this error, the media items I attach to the branch template don't really work when I create an item in the Media Library using that branch template.

It could be related to rainbow.config, I am not sure.

Does anyone have an idea?

3
What does your property look like you are adding to the branch? Where is the branch used? It's most likely because of something invalid in the item your are creating and it cannot save or create :) - Charlie Afford

3 Answers

0
votes

I went through stack trace you've provided.

Exception happens within

Sitecore.Resources.Media.MediaThumbnailGenerator.GetThumbnailFileName(MediaData mediaData, TransformationOptions options)

The only place where can be thrown System.ArgumentException with message 'Empty strings are not allowed.' and Parameter name: filePathOrExtension is ctor of GetFileIconPipelineArgs:

enter image description here

'cause:

enter image description here

I can assume that mediaData.Extension contains empty string. Getter of Extension property says that it uses 'Extension' field of media item.

So I suggest to check what is value of 'Extension' field of '/sitecore/media library/test image' media item. I'm sure you'll find that it's empty.

0
votes

I have the same error and realized that the error does not appear when an English item of the same version is present. My assumption is that the pipeline looks for a wrong version, meaning that English or the default language is used.

Here are all of my observations (haven't had time to investigate further):

  1. Issue appears only for versioned media items
  2. Issue appears only for non-English or non-default language (TBD)
  3. Issue appears when an item is selected for which no English- or Default-language version of the same value exists (e.g. when you request the item in German version 2 and there is only a version 1 in English)
  4. Issue persists in Sitecore 8.2 update 5

From my observations I assume that the getMediaStream pipeline overrides the requested language which leads to an empty value in the Extension and/or File Name.

The Sitecore client seems to send the wrong language to the server when trying to render the preview element. When I look at the German version of an item the request looks like this:

<SERVER URL>/sitecore/shell/Applications/-/media/<Item ID>.ashx?bc=white&db=master&h=128&la=en&mw=640&thn=1&vs=1&ts=e73e6b27-b0db-45d7-a3c9-29830ad0191a&udi=1

Note that the requested language is English. When I change the parameter to de, the request works.

Can anyone confirm this behaviour? It looks like a Sitecore bug to me.

0
votes

I got the same log error as well, but happened on attaching a new file (pdf) after detaching the older file. It was impossible to upload the new file, it simply wouldn't upload (got a nice asp.net error in the i-frame, with the same error as above).

I ended up deleting the media item completely and recreate it with the newer file attached, as a workaround.

Maybe a glitch, maybe a user issue... but not reproduced it yet. I'll get back on this, if I find a fix, or a how to reproduce at least.