OK, I think the problem is unique cache ID forcing. However, there are two things that don't add up.
1. This "forcing" is only done when there are non unique cache IDs in the database. So it is curious how the copy could be adding caches that cause non unique cache ID's in the destination database.
2. The time taken to do the force is unusually long. I have a laptop with similar specs. On my test database of 100,000 caches it normally takes just under two seconds to display fully when opened. If I use the GSAK sqlite manager to change some CacheIds such that now not all IDs are unique (thus causing the force unique cache ID code to activate) it then takes just under 4 seconds to open.
Regardless, you can test my theory that this is the issue by going to "Database=>Properties" and unchecking that option, then test again.
Image may be NSFW.
Clik here to view.
1. This "forcing" is only done when there are non unique cache IDs in the database. So it is curious how the copy could be adding caches that cause non unique cache ID's in the destination database.
2. The time taken to do the force is unusually long. I have a laptop with similar specs. On my test database of 100,000 caches it normally takes just under two seconds to display fully when opened. If I use the GSAK sqlite manager to change some CacheIds such that now not all IDs are unique (thus causing the force unique cache ID code to activate) it then takes just under 4 seconds to open.
Regardless, you can test my theory that this is the issue by going to "Database=>Properties" and unchecking that option, then test again.
Image may be NSFW.
Clik here to view.
