5.1a SR-1: Indexer Crashes at 99% Complete
This has been happening for me for the last few beta releases. My indexer nearly completes and then crashes (windows tells me that Logos has encountered an error and whether I want to close it or look online for a solution to the problem).
I'm using Windows7.
Logs attached.0576.LogosIndexerError_ryanschatz.zip
Comments
-
It looks like the indexer is failing at the very last step of merging indexes. The easiest way to fix it (although it will require a complete reindex) is simply to wipe out the existing index by deleting this folder:
C:\Users\schatzr\AppData\Local\Logos4\Data\ujcnlvdh.qnv\LibraryIndex
BTW, I noticed that you have at least one resource collection with the rule "title:*". You'll see a speed improvement in Logos 5 if you change the rule to just "*" (without quotes).
0 -
Bradley Grainger (Logos) said:
It looks like the indexer is failing at the very last step of merging indexes. The easiest way to fix it (although it will require a complete reindex) is simply to wipe out the existing index by deleting this folder:
C:\Users\schatzr\AppData\Local\Logos4\Data\ujcnlvdh.qnv\LibraryIndex
Ok, thanks... I'm reindexing now.
Bradley Grainger (Logos) said:BTW, I noticed that you have at least one resource collection with the rule "title:*". You'll see a speed improvement in Logos 5 if you change the rule to just "*" (without quotes).
Hmm... but this seems to change my results. For instance, I have a collection which is:
type:commentary AND (title:john OR subject:john) ANDNOT (subject:"1 John","2 John","3 John","John, 1st","John, 2nd","John, 3rd",epistles-of-john)
This produces 78 matching results.
If I replace it with the following, I get 489 matching results:
type:commentary AND (john OR subject:john) ANDNOT (subject:"1 John","2 John","3 John","John, 1st","John, 2nd","John, 3rd",epistles-of-john)
Am I misunderstanding you?
Thanks,
Ryan
0 -
Ryan Schatz said:
Am I misunderstanding you?
I think he is talking about a rule with the wildcard (*). Using a rule of title:* will reveal all resources with a title (in other words, your entire collection). Using a rule of just * will do the same thing, but be more efficient… At least, that is what I understood him to be saying. [:)]
macOS, iOS & iPadOS |Logs| Install
Choose Truth Over Tribe | Become a Joyful Outsider!0 -
Ah, I see it now. Got it.... thanks!
0 -
alabama24 said:Ryan Schatz said:
Am I misunderstanding you?
I think he is talking about a rule with the wildcard (*). Using a rule of title:* will reveal all resources with a title (in other words, your entire collection). Using a rule of just * will do the same thing, but be more efficient… At least, that is what I understood him to be saying.
and unless Logos have implemented a new feature in search evaluation which detects * and resolves the whole library without taking much time (just tested, seems not to be the case), using a rule like rating:<6 is much faster than both.
Have joy in the Lord!
0 -
NB.Mick said:
and unless Logos have implemented a new feature in search evaluation which detects * and resolves the whole library without taking much time (just tested, seems not to be the case), using a rule like rating:<6 is much faster than both.
Sure would have been silly for me to recommend an inefficient alternative.
0 -
0
-
Bradley Grainger (Logos) said:NB.Mick said:
and unless Logos have implemented a new feature in search evaluation which detects * and resolves the whole library without taking much time (just tested, seems not to be the case), using a rule like rating:<6 is much faster than both.
Sure would have been silly for me to recommend an inefficient alternative.
I was hoping for the new feature, that's why I "tested" before. However, it seems I was too lazy: I input these rules into the library search/filter field. On my old machine it takes roughly two minutes to re-populate the nearly 6k resources library with any of the two wildcard searches discussed here - rating:<6 works in an instant. However, populating a new collection rule field for any of the three works in an instant.
For testing collections, I now build three of them called SPEED Test 1 through 3, each with an "all but Perseus" rule.
I did restart Logos and checked the logs - what I see is that you now convert * -perseus to a search [inverted] perseus - whereas (title:*) -perseus stays as it was. Rating:<6 seems to be built elsewhere, but rating:<6 -perseus is not shown as an index search, maybe this also is converted to [inverted] perseus - unfortunately I can't read logs well enough to ascertain the time needed for each of these and I restarted Logos again without saving this log (and the new logos.log file doesn't show any collection rebuild lines - which probably is good, since startup was much faster), thus now I can't show the logs). [inverted] seems not wo work in manual rule input for collections or the library filter, though.
It would be really nice to see this faster interaction in the library filter.
Have joy in the Lord!
0 -
NB.Mick said:
whereas (title:*) -perseus stays as it was
"title:*" (and "type:*") is an obvious improvement that we can add to the current logic.
NB.Mick said:but rating:<6 -perseus is not shown as an index search, maybe this also is converted to [inverted] perseus
It is, as well as "rating:>=0 ANDNOT ..." and "rating:<=5 ANDNOT ...".
NB.Mick said:
It would be really nice to see this faster interaction in the library filter.
The library filter sorts the results by Rank (even if you choose to reorder the results by Title in the grid view), which isn't compatible with some of these optimisations. (Resource Collections don't have an implicit order, so there are more opportunities for optimisation.)
I agree that it would be nice if the Library benefitted from these optimisations, and I'll see what's possible there.
0 -
Thanks a lot for improving our Logos experience everyday!
Have joy in the Lord!
0
