Hi
After a recent update this happens:
When I click on a link in an email GO opens and it loads the cache. After a while the list @install is shown that contans the cache, but the cache itself is not opened/shown.
In addition, when selecting the list @install it takes about 5 seconds before the list is actualy shown. This was not the case before.
/Picht
Can you forward the email so I know exactly what you are working with?
Happens to all links.
E.g. https://coord.info/GCABWMG (https://coord.info/GCABWMG)
I know the URL format. I was more interested in how it was being displayed in an email.
I'm not sure how the link displayed in the email has to do with the error that I report?
If I take the link from above and send it to myself in an email and then click on it the same happens as described in the first post.
/Picht
Well, because some email programs don't format the same way particularly in identifying there is a link in the message.
Regardless, it seems to work fine for me. So, something else is going on.
I just did some more testing:
I deleted the @intall
Now it works sometimes and sometimes it doesn't.
I will see if I can do some more testing and make it reproducible.
Maybe the amount of caches in the @install has something to do with it...
The number of caches in the Install list shouldn't be a problem, but maybe there is something I don't see. I have 20 in my list.
Let me know what you uncover in testing.
Hi
I haven't been able to figure out why or when, but I have a screenvideo of when it doesn't work.
Also note how long it takes from the download finishes and until the @install list is loaded
Regards
Picht
What happens if you turn off the distance sorting for the Install list? It will take some time to obtain the coordinates of each cache before sorting. And that activity is occurring while building the list for display. I may have to force a sort delay until the list is fully rendered.
How do I do that?
If I enter bthe list and removed the sorting and exit the list, then when entering the list again it is sorted again
/Picht
In Settings in the List section, you probably have Sort Lists by Distance checked.
Removing the sort by distance didn't help
Also the long load time for the @install list is still there
/Picht
Have you turned on the Download Cache Description Images setting in the Geocaches section? If you export settings, I could review them.
To experiment, you could try transferring all the caches to another offline test, both Full and Lite, to see if the behavior changes. Other than that I can't think of a cause.
No, it is not turned on.
Settings attached
Would deleting the @install get the same result that you are looking for?
I have done this and now there is only 7 caches in the list and the error is still there...
Nothing looks like a problem with settings.
No, deleting the Install list isn't the same for the test. I'm trying to determine whether the caches are a problem or the Install list itself has an issue. By putting caches in a separate list removes the Install list concern. I have many more caches in my Install list, but it opens nicely as shown in the video I attached. Maybe the event caches are the issue so if in another list they show the same slow opening, then I would focus on caches.
I moved the 7 caches in the @intallist to another offline list.
Now when I click on the link in the email it works.
How does that other offline list work? If still slow, send me a GPX of them.
If the main problem with the link for Install is not showing the cache page after it was downloaded, I will need to delay the display of the page to give the app more time to open the Install list before showing it.
Now both opening the @install that has 2 caches and opening the Xxx, containing the 7 caches moved from the @install, are slow when opening. Frm clicking it takes around 4 seconds before the list is opens
Have you confirmed that a list without events works fine? Since the Install list is nothing but events, I think that is part of the issue. When getting a list for display, Geooh checks with Groundspeak whether an event in the list has a Will Attend log for you. So for you, there are multiple API calls for each event before it can display the list... which will slow things down.
I'll work on delaying event API calls until after the list is shown and then update to Will Attend icons as needed. It was a user benefit to let you know if an event in a list has a Will Attend by you.
Lists wich "normal" caches seem to work fine
Good idea!
Yes, I like that feature :)
The app has been reworked to check for attend logs in the background so it should not slow down opening any list with events. Please verify when the next maintenance release comes out soon.
It was good to know this had a potential slowdown when there are lots of events... which could happen in the #Events quick list.
Glad to be able to help making the app even better :)