markens

My browsers actively prevent connecting to the site when this happens, with no way to override. It's a security error. I'll note more detail next time it happens.

Hi Nic, It seems that access to the forum is increasingly interrupted with "unable to securely connect" errors lately. This generally indicates a server certificate error of some sort. It lasts a day or two, then all is okay again for a while. When it happens, I see it in different browsers. Any idea what's up?

Open the App Store. Then, in order: tap the profile icon in upper right corner; tap "purchased" near the top; tap "My Purchases"; type "cachly" in the Search box and tap Search button. There should be an entry for cachly with a cloud download icon. Tap that and you should be in business.

With regard to the PQ issue: could it be that the PQ rework project underway at groundspeak has affected this functionality? They seem to have broken a number of PQ features. See this thread: https://forums.geocaching.com/GC/index.php?/topic/382502-release-notes-website-pocket-query-api-october-18-2022/

I like and use the cachly feature which lets me set the status of individual adventure lab stages to FOUND, which then shows those stages with a smiley on the map. This works great on labs imported via GPX. But I have not found a way to do this on lab stages loaded in the live view via API, which are then added to offline list(s). For those loaded via API, the current abilities are good (see stage info, navigate to the stage, and load the stage in the Adventure Lab app). It would be very useful to add a fourth option to set the stage to FOUND in cachly. Thanks! BTW, I love the ability to search an area for all ad lab stages in that area. This is so incredibly useful, and a feature sorely missing in the geocaching HQ apps. Well done, Nic.

I sent a video and details to Nic via PM.

I'll have an opportunity Thursday, and will try to capture a video.

I've noticed this as well, very bizarre behavior. No idea how to replicate it since it happens when re-opening the app after being on the move. I'll try to notice whether it matters if cachly is running in foreground or not, and more specific details about when this behavior occurs.

Wouldn't it be straightforward to apply such a filter locally after the results are returned by the API (which would give the user the same effect)?

I had the same issue. Just updated to cachly 6.1 which indeed fixed the problem. Thanks!

I second this request! This is my work flow as well, and I routinely empty a list manually before importing gpx from gsak. The requested function will be very useful.

I thought I tried this via the offline list ... button, and it only removed highlights from those caches currently in the list. Does this really remove highlights in other lists as well? Seems it should just be the current list. But the other option you mention (More tab) appears to be what I'm looking for, removing highlights across all devices and lists. It currently shows 643 highlights for me, which is exactly what I want to clear! I will try this when I'm done with current set of active highlights. A bit of background: I import caches into offline lists from gsak. I liberally use the gsak "user flag" method for setting highlight upon importing into cachly. And I often empty an offline list before importing more caches into it, leaving behind the highlight attribute. When I load a new set of caches (with different user flag/highlight combinations), the previous highlight attributes reappear on caches I don't want highlighted anymore. Being able to do a global clear of highlights solves my immediate issue. But a slight modification of the import process into cachly would make this much easier. My suggestion: When importing a gpx file into an offline list, first check to see if the gsak user flag is set for *any* cache in the set. If so, then that implies that the lack of a user flag is also important. Therefore, set highlight for caches with the user flag set, and *remove* highlight from caches with the user flag not set. (If the user flag is not set for any cache in the gpx file, then simply ignore stored highlight attribute as now happens.) To me, this is expected behavior when using the gsak user flag in this manner. If you don't want to make this default behavior, perhaps it could be made an option along with recognizing the user flag in the first place. Thanks!

Questions about behavior of highlight attribute for caches in offline database. From what I see, the highlight attribute persists in the database even after the cache has been deleted from all offline lists. And so that same attribute is applied when an affected cache is seen again in an online search, or added to an offline list. While not expected, this behavior is useful much of the time. If a highlight needs to be adjusted or removed, it can be done as usual when a cache reappears on a list. But it would be useful to be able to remove the highlight attribute from all caches in the offline database, to prevent them reappearing again on new searches. Is it possible to do this? Other than deleting the app and reinstalling? Thanks.

Thanks!

Also rebooted my phone with no change in behavior.