none
Search Export Converter Stage Error RRS feed

  • Question

  • Anyone getting "no filter available" error message from the Search Exporter pipeline stage for valid Office Documents?

    Format Error[documentid="xxxx" code="15" description="Conversion failed: EXOpenExport() failed: no filter available for this file type (0x0004)" suggested action="drop" component="processing" processor="SearchExportConverter-Timeout-600"]


    We are seeing this for office documents that can be opened in there respected applications. Today we started seeing a warning because we change how our code and pipeline handles mime-types. We are now passing in the mime from the CMS and letting the format detector stage fallback to the passed in mime if it can't be detected. Anyone seen this warning?

    Generic Warning[documentid="xxxxxx" code="0" description="Overriding input mime-type application/vnd.ms-excel.sheet.macroEnabled.12 with detected mime-type application/x-stellent-1819" component="processing"]

    Thanks,

    Jeremy

     

    Thursday, February 3, 2011 9:11 PM

Answers

  • I was able to work around this issue by creating a custom format detector stage that allowed me to pass the MIME type.

    I'm using the JDBC connector, but you could also use the Fast Content API to specify the MIME field.

     

    Here is some sample code:

     

    doc.AddElement(

    new StringElement("mime", "Application/PDF"));

     

     

     

    Friday, April 29, 2011 12:52 PM

All replies

  • Hi Jeremy,

     

    ESP should not have a problem with xlsm documents (mime-type application/vnd.ms-excel.sheet.macroEnabled.12), so I'm not sure why the Search Exporter stage would be overriding the mime-type.  It could be the version of ESP you are running - what version and patch level are you on?  I can check to see if there are any newer patches that could help you.  Another possibility is the encoding could be wrong.  Otherwise you may want to consider opening a support ticket as this could require a deeper look.

     

    Thanks,

    Patrick Schneider


    Patrick Schneider | Microsoft | Enterprise Search Group | Support Escalation Engineer | http://www.microsoft.com/enterprisesearch
    Friday, February 4, 2011 8:49 AM
  • Thanks Patrick. We are running 5.3 slipstream SP4. We have all the latest patches.  I opened a support ticket and posted to the forum just to see if we got a quick answer.

    One thing I did notice is that our mimemapping.cfg file in the FormatDetector config_data does not have the XLSM mime type correct. It shows without the .12 at the end. Could that be an issue?

     

    Friday, February 4, 2011 1:13 PM
  • I don't think the mimemapping.cfg file will be the problem.  I suspect it may have something to do with the way your connector is sending the data.  A quick test you can run is to manually add the document to the collection you are feeding to - either through the Admin GUI or by using docpush.  If the document is processed properly, you will know to take a closer look at what your custom feeding application is doing.  If it still isn't processed properly, the pipeline may be the culprit.

    Thanks,

    Patrick


    Patrick Schneider | Microsoft | Enterprise Search Group | Support Escalation Engineer | http://www.microsoft.com/enterprisesearch
    Friday, February 4, 2011 2:19 PM
  • We found that the searchexport pipeline stage does not behave the same for 2007 or greater Office documents as it did for 2003 or less.  However the docexport searchml_32 does give the same output error message for all documents.  I have a support case in for this and it is with the engineers now. Just wanted to give an update.
    Thursday, March 3, 2011 7:49 PM
  • Is there an update after that? Would be nice to learn the cause of this issue. Thanks !!
    Freddie Maize ..A story with Glory is History. Doesn’t matter whether Glory rest in the world of Demon or God. Lets create History..
    Monday, March 28, 2011 9:49 AM
  • Freddie,

    The issue is a bug within the export pipeline stage.  The issue has been turned over to R&D to get into a patch. Basically the newer Office documents don't behave the same as the old Office docs and basically returns the generic "No filter available" error message for any error within the newer documents. 

    Thansk,

    Jeremy

    • Proposed as answer by Ted_Broyles Friday, April 29, 2011 12:47 PM
    • Unproposed as answer by Ted_Broyles Friday, April 29, 2011 12:47 PM
    Monday, March 28, 2011 1:07 PM
  • I was able to work around this issue by creating a custom format detector stage that allowed me to pass the MIME type.

    I'm using the JDBC connector, but you could also use the Fast Content API to specify the MIME field.

     

    Here is some sample code:

     

    doc.AddElement(

    new StringElement("mime", "Application/PDF"));

     

     

     

    Friday, April 29, 2011 12:52 PM
  • hi,

    which patch is the fix released?

    thanks,

    ken

    Tuesday, October 4, 2011 7:04 AM
  • Ken,

    It was determined this behavior is as intended by the third party vendor that does the external document conversion in the search exporter stage. There will be no patch and my support case has been closed.  You can use the marked answer as a workaround, but for our case it wasn't sufficient.  I'm now looking into a way to open Office documents using the Office API and determine myself before pushing it into ESP if the document is corrupt, password protected, etc.

    Thanks,
    Jeremy

    Tuesday, October 4, 2011 11:36 AM