Error library index could not be retrieved

• Remove From My Forums

• Question

• I am getting the next error when i try build in TFS2013:

  Indexed source information could not be retrieved from C:Builds2CompanySolutionBinariesAntlr3.Runtime.pdb. Error: Symbol indexes could not be retrieved.

  the files exist in path.

  thank you for your help

  ---

  steve

  SOLUTION: 

  i remove files pdb of source control, now it is build right 

  thanks 

  • Edited by

    Tuesday, February 10, 2015 2:16 PM

Copied to clipboard

• 

   2015-12-22 16:09:14,444 [P3076/D3/T119] WARN  Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedMediaCache - Could not retrieve media 1217 from Examine index, reverting to looking up media via legacy library.GetMedia method
   2015-12-22 16:09:15,038 [P3076/D3/T119] WARN  Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedMediaCache - Could not retrieve media 1217 from Examine index, reverting to looking up media via legacy library.GetMedia method
   2015-12-22 16:09:15,366 [P3076/D3/T119] WARN  Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedMediaCache - Could not retrieve media 1217 from Examine index, reverting to looking up media via legacy library.GetMedia method
   2015-12-22 16:09:17,642 [P3076/D3/T11] WARN  Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedMediaCache - Could not retrieve media 1262 from Examine index, reverting to looking up media via legacy library.GetMedia method
   2015-12-22 16:09:17,658 [P3076/D3/T11] WARN  Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedMediaCache - Could not retrieve media 1687 from Examine index, reverting to looking up media via legacy library.GetMedia method
   2015-12-22 16:09:17,674 [P3076/D3/T11] WARN  Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedMediaCache - Could not retrieve media 1684 from Examine index, reverting to looking up media via legacy library.GetMedia method
   2015-12-22 16:09:17,700 [P3076/D3/T11] WARN  Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedMediaCache - Could not retrieve media 1683 from Examine index, reverting to looking up media via legacy library.GetMedia method
   2015-12-22 16:09:17,700 [P3076/D3/T11] WARN  Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedMediaCache - Could not retrieve media 1685 from Examine index, reverting to looking up media via legacy library.GetMedia method
  

  Ad infinitum…

  We’re getting this message constantly in our log files.

  It’s a single, non-scaled webapp on Azure. We are using the UmbracoFileSystemProviders.Azure plugin to store/retrieve media in blob storage but that is simply an IFileSystemProvider implementation which shouldn’t affect Examine. The Image doctype has also been altered to use the ImageCropper rather than FileUpload though that should cause any issues either.

  Any ideas?.. It’s driving me bonkers.

• 

  Is there by any chance any errors when indexing media? I’ve had weird issues with examine when I had a custom property with the same name as a built in one. For example ‘id’.

  You could try and download the examine index and open it with Luke, and see what kind of data is in there. Then you can determine if it’s the read or the write that fails.

• 

  Cheers, I’ll do that.

  There’s no errors thrown on node gathering though and We’re only adding to a custom, non-duplicated field. It’s very odd!

• Sunnefa
  
  22 posts
  
  41 karma points

  Jan 28, 2016 @ 16:09

  

  Are there any answers to this? This is happening on a live site and causes the log to become several hundred megabytes.

• Bruce
  
  4 posts
  
  24 karma points

  Feb 05, 2016 @ 15:05

  

  I see a similar issue on a recently upgraded site (from 7.2.1 -> 7.3.5). Not hosted on Azure. It reports:

  Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedMediaCache — Could not retrieve media 0 from Examine index, reverting to looking up media via legacy library.GetMedia method

  And it gets logged about 40 times per minute — resulting in really long log files.

  Is there an option to stop «WARN» items getting logged?

• 

• 

  I have just updated to umbraco v7.3.7 and can confirm that for my instance the log file no longer displays these warnings.
  This is true for both azure and local development.

  Note that the error can still show up if you have a media item in the recycle bin and open it in the recycle bin. It can also shows up in the log if it is referenced by another item that is still published.

• 

  That’s great news thanks for the update!

• 

  Hmmm… I think we were too quick to close this. I’m still getting the very same error on a v7.4.1 build.

• 

  Hi James,

  Just to report I’m also seeing the same error on an install I upgraded from 7.2.8 to 7.4.1, at a frequency of several a minute.

  Cheers,
  Chris

• 

  Hi All

  Has anyone found a solution to this problem? I have recently deployed a 7.4.1 instance and am getting this error in the logs multiple times per second. I’m also not seeing any images on the site as the called to Umbraco.Media(id); in my razor is what’s triggering these errors.

  The site is on a 2 server web farm, with a shared file storage (IIS accessing via UNC paths) — permissions are all correct and the External Examine and Member logs are all working as expected.

  Any help greatly appreciated.

  Thanks,
  Dave

• Jonas
  
  123 posts
  
  206 karma points

  Apr 07, 2016 @ 12:22

  

  Same here , logs filling up quickly.

  Umbraco version 7.3.8 assembly: 1.0.5891.22674

• 

  Hi Jonas

  I discovered that in my case the content api was returning a null value for these properties, which was caused by something going wrong during our data transfer process to the live servers (still not sure what exactly). So we ended up just manually resetting these.

  We changed our code to check the property value (value of id) was > 0 before called Umbraco.Media(id) which has reduced the log errors massively.

  Dave

• 

  That happens because somewhere the code is accessing media nodes that don’t exist in the Examine index.

  The code below will fix this problem by indexing all media nodes that don’t exist in the Examine index.

  @inherits UmbracoTemplatePage
  @{
      // Retrieve all media nodes 
      var xmlMediaNodes = new List<IMedia>();
      foreach (var mediaNode in ApplicationContext.Current.Services.MediaService.GetRootMedia())
      {
          xmlMediaNodes.AddRange(ApplicationContext.Current.Services.MediaService.GetDescendants(mediaNode.Id));
      }
  
      //Retrieve all media nodes from lucene index (InternalSearcher)
      var searcher = ExamineManager.Instance.SearchProviderCollection["InternalSearcher"];
      var searchCriteria = searcher.CreateSearchCriteria(Examine.SearchCriteria.BooleanOperation.And);
      var query = searchCriteria.RawQuery("+__IndexType:media");
      var luceneMediaNodes = searcher.Search(query).ToList();
  
      // Index media nodes that exist in the xml cache but not in the lucene index
      var nodesReindexed = 0;
      foreach (var mediaNode in xmlMediaNodes)
      {
          if (!luceneMediaNodes.Any(x => x.Id == mediaNode.Id))
          {
              ExamineManager.Instance.ReIndexNode(ApplicationContext.Current.Services.PackagingService.Export(ApplicationContext.Current.Services.MediaService.GetById(mediaNode.Id), false), UmbracoExamine.IndexTypes.Media);
              nodesReindexed++;
              // As more nodes are indexed, more time is given to lucene to re-index
              System.Threading.Thread.Sleep((int)Math.Truncate(Math.Log(nodesReindexed) * 50));
          }
      }
  }
  

  You will still get a warning when you try to access a media with Id 0. This has been fixed in Umbraco 7.4.2 (http://issues.umbraco.org/issue/U4-7823)

  If someone is wondering where this warning is coming from, take a look at: https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web/PublishedCache/XmlPublishedCache/PublishedMediaCache.cs [line 224]

  Hope that helps.

• 

  Hi All,

  We are still getting this error message on a 7.4.3 installation.

  It’s becoming a major issue for our client, it can easily be replicated by them deleting a node that is referenced in a multi-node picker.

  As soon as the Examine index tried to re-build we get a flood of these errors and it seems to slow the index building significantly which is not good when they have 25k nodes.

  Did anyone create an Umbraco Issue for this?

  Cheers,

  Chris

• 

  Hi Chris – I’ve not created an issue for this, and still haven’t managed to find a resolution.

  Chris

• 

  See new issue http://issues.umbraco.org/issue/U4-8856

  Can flood the log if eg a site contains many media pickers and the picked medias have been deleted => will write 1 line per media = bad.

  Stephan

• 

  Hi Stephan,

  I see the issue with the logging has been fixed but we have a problem when it falls back to the db lookup instead of examine if you are fetching a folder they have no children but if you get it from the examine index it does have children.

  So the fallback method isn’t a replacement for the examine version.
  We allow users to pick a folder rather than individual images and it’s become quite an issue for us.

  This happens on our sites a lot our logs are full of these message and makes me concerned that the examine index becomes corrupted/invalid very frequently

  Steve

$begingroup$

htseq-count -m intersection-nonempty -f bam -i gene_id -r pos -s reverse ./OVCA429_Aligned.sortedByCoord.out.bam ./GRCh38_latest_genomic.gtf > ./OVCA429.counts.txt

[E::idx_find_and_load] Could not retrieve index file for './OVCA429_587680_1_1.rnaseq.fastqAligned.sortedByCoord.out.bam'
100000 GFF lines processed.
200000 GFF lines processed.
300000 GFF lines processed.
400000 GFF lines processed.
...(truncated output here)...
3775001 GFF lines processed.
[E::idx_find_and_load] Could not retrieve index file for './OVCA429_587680_1_1.rnaseq.fastqAligned.sortedByCoord.out.bam'
100000 alignment records processed.
200000 alignment records processed.
300000 alignment records processed.
...(truncated output here)...

Output text file:
__no_feature    20368875
__ambiguous 0
__too_low_aQual 0
__not_aligned   0
__alignment_not_unique  2634439

$endgroup$