OSAK becoming non-responsive

[CheminerWill]

Description

Can't really provide too many different specific steps for this one but it happens randomly and frequently for me with 15 beta7. But one thing that causes it without fail is if I am in my test db with a few caches and use the manage databases menu to change to my other db which has 19K caches in it. It will stop responding for at least 45 to 60 seconds when I try to switch, then eventually the "not responding" message will go away and the db will load. I thought maybe it was something in my setup as I have had so many versions and dbs installed and uninstalled over the past few weeks. So I cleared everything out. Got rid of all old versions on my computer. Deleted 15 Beta7, and also deleted my entire OSAK folders and databases etc. So as far as I could tell there was no trace of OSAK left. Then restarted the computer to clean any other possibilities out. Then I re-downloaded 15 Beta7 and installed. Of course all settings, columns etc. were back to default but I left that as such. Then used the new menu item to "Import From GSAK Database" to import my big GSAK Db with 19K caches. Still having the same non-responsive problem. Realize maybe it has to do with the size of the db? BUT I have used this same db with previous versions and it never happened.

Steps to Reproduce

Described above

Expected Behavior

Not to become non-responsive.

Environment

Win 11

[AgreeDK]

@CheminerWill
Thanks for reporting this, I will try to solve it based on you current input.

[AgreeDK]

@CheminerWill
Thanks for the detailed report. I tried reproducing this with a synthetic ~8,000-cache database and profiling the exact code path used on switch (query + info bar) — it completed in under a second, so the list-loading logic itself doesn't appear to scale that badly at rest. That points me toward something environment-specific rather than an algorithmic issue in the switch code itself.
Since you're on Windows 11, a few things that would help narrow this down:

Is the folder your databases live in excluded from Windows Defender (or any third-party antivirus) real-time scanning? Defender re-scanning a large .db file on every open is a very common cause of freezes that scale with file size — and would explain why it kept happening even after your clean reinstall (a "new" file still gets scanned).
Is that folder inside OneDrive (or any other cloud-sync folder)? OneDrive can lock/hold files during sync in a way that blocks access for tens of seconds.
Does it freeze on every switch to the 19K db, or only the first one after opening OpenSAK?
If you open Task Manager during the freeze — is a CPU core pegged at 100%, or is disk activity high with low CPU? That would tell us whether OpenSAK's own code is busy, or something else (AV/sync) is blocking file access.
Roughly how many logs/attributes/waypoints per cache does your 19K database have on average? GSAK's own log history in particular can be very large per cache, and that's one of the few things that scales with real-world data in a way my synthetic test database might not have captured.

[CheminerWill]

I will try to answer your questions as best as I can. Remember, however, that none of what you are asking about has changed and previous versions of OSAK did not do this.

I have never since I started using version 1.13 excluded the database folder from Windows Defender or Avast Antivirus. If that is an issue, why would it start with this version and not have been a problem with previous versions?

No, the OSAK database folder is not inside OneDrive.

It stops responding every time I switch to it. It does it when I open the program if that is the db open at the time. If I switch over to another db with only a few caches all is fast and good. Then if I switch back to the big db, it becomes non-responsive until the caches are populated.

Task Manager shows both CPU and Disk as low while waiting for the db to load. (Single digits)

Many of the caches in the db are old and I have all logs. So many have over 100 logs. But again, that has not changed since previous version of OSAK which did not do this.

Another note - I can make it freeze for 30 seconds or so by clicking the "Refresh" button and also the View>Refresh List tab. I can also make it freeze by filtering. If I uncheck all the cache types and then check only one type to filter for, it freezes. If I filter for distance, it freezes. If I have a filter set and then click the red X to clear it, it freezes. If I have no filter set and then filter to have difficulty only up to 3 and not 5, that freezes it. There are many things I can do that probably involve the program going through all the caches and they all seem to freeze it temporarily. It never crashes, it always comes back with the correct result of what I am trying to do. Just pauses with the Not Responding message for a while before it does.

There are other things that do not freeze. For example, clicking column headings to sort happens as quickly as ever.

Edit: Noticed when testing the Premium Cache bug I think I have that when I run that filter in OSAK it responds immediately that there are no premium caches. No delay or unresponsiveness at all.

[AgreeDK]

@CheminerWill
Thanks again for you time and effort to reply and report back.

I understand your point, but when we cant reproduce it , we want to make sure we dont miss any reason why you have the issue. We will keep working until it is fixed.

[CheminerWill]

I just ran 15 Beta 5 on the same db and it all works as it should. No delays or freezes. So that would seem to indicate it is beta 7 causing it. Maybe tomorrow, I can send you my actual 19K cache db somehow? Maybe upload it to this issue? What would be the best way to get that to you so you can see it in real time by using my actual db?

Edit: When I first did the GSAK import I just put it into the "Default" db in OSAK. That would not have done anything would it. Since the GSAK database was named "Southern Oregon, not Default? Strike that thought. If that was an issue it would freeze in Beta 5 also I suspect.

It is late here even for a night owl like myself so my brain is needing to go to sleep. I will check this thread in the morning and see what you suggest next of if anything has been figured out.

Here is a shot of the files in the OSAK database folder:

[AgreeDK]

@CheminerWill
Thanks again, i will compare beta.5 with beta.7 in detail, then I should be able to find what part of the code made the problem.

[lignumaqua]

Couple of comments re GSAK. GSAK tries to use in-memory tables as much as possible for temporary tables to try and keep away from Windows poor handling of these small transactions. However, we still recommend exempting the database folder from real time AV scanning. Windows Defender is really intrusive.

As to database size - the largest database a user ever sent us for testing was 29GB!!

[AgreeDK]

@CheminerWill
We have made a fix in beta.8 version, so please retest and let us know the result, thanks.

[CheminerWill]

Yes it now seems to all work as it did in previous versions. Thanks! I was concerned this one might be related to something specific in my db and hard to track down. Glad you got it sorted.

[AgreeDK]

as it have been fixed, I will close it.