Bug: ESV non-responsive when opening for first time

This has been happening for some time with v7.x. After opening Logos to my modest layout (below) and clicking the ESV tab there is a delay, Logos becomes non-responding and when it finally opens it has swapped places with BKC.
Visual filters:
- Addressee
- Corr Selection
- Emph Active Lemma
- Speaker Labels
- 1x Note file (small)
- 1x Basic search VF on Translator's Note field
Dave
===
Windows 11 & Android 13
Comments
-
Concur opening resource(s) with Visual Filters enabled is unresponsive plus has no indication that visual filter highlighting is in process. At times, dream about a banner similar to Search when Indexer is running about Search results being incomplete, which would help show Logos 7 is busy searching and applying visual filters (and have banner disappear when done).
Keep Smiling [:)]
0 -
Firstly, there appears to be a huge amount of background activity going on:
- Resource updates
- Metadata updates
- Document indexing
This is all causing a lot of contention on the disk. (If this is happening every single time you run the application, then something is wrong and we need to dig into that more.)
The performance problem with the ESV may be related to visual filters. Firstly, try disabling non-search-based Visual Filters, such as reported speech. Also try turning off the reverse interlinear ribbon (or inline display) if you have those on. Does this improve performance at all?
Secondly, we can look into how much of a problem search-based VFs are. These are evaluated on a background thread so they shouldn't freeze the UI, but they may cause disk contention that blocks UI operations. The VFs that seem particularly slow are:
- you NOTEQUALS <LN 1-93>
- he NOTEQUALS <LN 1-93>
- "signs of the end", "nation will rise", "hear of war", "false christ", earthquakes, betray, hatred, abomination
- lemma:εἰ@CAC BEFORE 7 words @V??I
- lemma:ἐάν@CAC BEFORE 6 words @V??S
- lemma:εἰ@CAC BEFORE 6 words @V??O
- <Bible jn 3:16>
- "some manuscripts add", "some manuscripts insert", "some manuscripts omit"
- "son of man" NEAR (clouds, power, glory)
- {Section <PreachingTheme Marriage>}
It's not sufficient to simply uncheck these on the VF menu; you need to delete them (or change them to apply to a resource other than the ESV). Does doing that improve anything?
0 -
This is all causing a lot of contention on the disk. (If this is happening every single time you run the application, then something is wrong and we need to dig into that more.)
It doesn't seem to be an issue when the layout is loaded with ESV tab open
This is the most recent attempt to open ESV from within the layout, without an issue.
The main point is that the "not responding" issues happens frequently whereas it had not been a problem with Logos 6 - the search VF's have not changed.
It's not sufficient to simply uncheck these on the VF menu; you need to delete them (or change them to apply to a resource other than the ESV).
I'll respond to this ASAP.
Dave
===Windows 11 & Android 13
0 -
Dave Hooton said:
It's not sufficient to simply uncheck these on the VF menu; you need to delete them (or change them to apply to a resource other than the ESV).
One log shows opening ESV with VF's and no issue. The other shows opening ESV with no VF's (response time similar to previous case).
Dave
===Windows 11 & Android 13
0 -
If I'm understanding you correctly, in all four logs you posted (two on each reply), the "ESV non-responsive" issue did not occur; is that correct?
If that's the case, then it seems that the number of enabled VFs has little to do with the performance of opening the resource panel. Instead, the problem may have been all the background work that I mentioned in my previous reply. And if you've been able to open the ESV a number of times without problems, then is it the case that the issue occurs infrequently?
0 -
It happened frequently in v7 prior to creating this problem report, but never in v5/6.
Since creating this report it has happened a few times. The period that applies to these logs is too short to conclude that the issue occurs infrequently.
Dave
===Windows 11 & Android 13
0 -
The issue definitely arises during a download when 98%+ disk activity is reported, or whenever the system is responsible for that disk activity.
Dave
===Windows 11 & Android 13
0