barefootguru

Much the same as @AnyMules but I don't use TBs… and couldn't recreate just now.

That’s good to hear Nic — GS do seem good at the day-to-day work.  It’s the overall business direction which frustrates and worries me — e.g. the way logging NM through the website has been ruined; and not accepting new API partners.

I just hit the GPX file button for GC3PKD6, and checked a hex dump of the latest log entry (by bruzie).

        <groundspeak:log id="754128042">
          <groundspeak:date>2018-03-27T19:00:00Z</groundspeak:date>
          <groundspeak:type>Found it</groundspeak:type>
          <groundspeak:finder id="6636635">bruzie</groundspeak:finder>
          <groundspeak:text encoded="False">A big day over in the Wairarapa today, picking up a few A-Z caches and as many 2:2 caches as I could, plus attempting to clear the Planetary Pursuit challenge in one day.

This was the reason for heading up this road, my second-to-last find on the level 2 caches. The cache was a quick find and still nice and safe. Now to carry on up the road a little bit further. TFTC</groundspeak:text>
        </groundspeak:log>

1 hour ago, TheWinterTrio said:

And just to be clear...  I don't see the "<BR/>" in the log as displayed in Cachly, it appears to ignore them and all the fields run together.

I was suggesting using LF characters (0x0A) instead of <br/>, as that's the norm for GPX files, and Cachly will honour the line breaks.

I tested this with a cache where there were newlines in a log entry… the GPX just has LF characters (0x0A).

I’m puzzled about what all that info is doing in your log entries?!

@rragan I’m pretty sure GSAK only uses the GC API — no screen scraping?

FWIW I also strike this every month or so.  The most recent log seemed to lose the data as soon as I saved the pending log.  I don’t use templates but have a default Found It and often insert owner name as a keyword.

This came up before, with much the same responses 

Cachly is slow at rendering the offline maps, and Nik says this is hard to speed up.

If possible, I think it would help to:

1. prioritise rendering around the current location
2. when zooming in, don't clear the map — instead do a crude zoom on the current bitmap while the higher zoom renders in the background
3. display layers as they're rendered, rather than wait for them all to finish.  You could e.g. prioritise tracks over playgrounds.

Thanks!

Been working with Nic on the crash, it should be fixed in the next beta 

Does anyone use the newish drafts feature for this?  Maybe it’s a topic for the wiki 

Seems like I could use drafts instead of pending logs, then be able to edit & submit from any device/browser?

But knowing GS there’s probably caveats!

I suggest each How To be a seperate page:  the combined one is going to get unwieldy, plus easier to link from e.g. main page.

Hi, Cachly 4.1 seems pretty good on the refresh speed, but still crashes towards the end.

I removed the old version before installing 4.1

Have e-mailed one of the crash logs.

I meant adding some text explaining you need to request access to edit the wiki.

It's off-putting having your edits silently ignored, and people are used to wikis allowing changes.

Will do.  You might want to add something to the main page or signup process explaining the above.

I created an account on the wiki, edited a page (‘minor edit’), and hit Save, but the changes don’t stick.  Have tried reloading the page.  Do I need to be approved?

From my experience iOS will keep updating the location when stopped if you’re in a program which is asking for it — such as tapping your current location in Cachly, or sitting on Cachly’s Compass screen.

Cachly does make its entire database available through iTunes (device > File Sharing > Cachly > Cachly.sqlite), and I suspect the DNFs will be in a separate table, but you'd have to know SQL to go that route.

Personally, even the living aren't that interested in my hobby 

p.s. looks like you can get a list of DNFs which haven't subsequently been found with GSAK https://project-gc.com/qa/?qa=8983/search-dnfs-not-subsequently-found, which could then be exported.

On 26/02/2018 at 1:21 PM, wuthred said:

The My Finds PQ only includes DNFs for caches eventually found. Cachly has all my DNF logs. Is there any way the Logs feature in Cachly could export everything in CSV format for extracting in a spreadsheet? Or please tell me it already exists. Thanks. 

You can see your DNF logs through the website, though it also includes those you’ve subsequently found.

https://www.geocaching.com/my/logs.aspx?s=1&lt=3

I think there's a date bug in the Date Downloaded filter, maybe because I'm in New Zealand… and currently on daylight saving — NZDT, UTC+13.

I'm looking at a cache which says 'Downloaded on 20/02/2018 at 11:59' (which is correct).

If I create a filter with Type=Date Downloaded, Date=19/02/2018, Logic=Earlier than or on, Invert Filter=No; then I still see the cache.

If I change the date to 18/02/2018 then it's hidden as expected — so 2 days out?

Cachly 4.0.1, iOS 11.2.5

I just refreshed the list in chunks, using Visible Caches, and it went fine — thought it might be a bad cache.

This may be the opposite of helpful   I'm still running 3.1 on my iPad, with the same list of offline caches, and it's still updating fine.

Could it be the image downloads?

3 hours ago, Nic Hubbard said:

No, this isn't true. That message is shown if you have exceeded 30 API requests in the last 60 seconds. There are instances where you would have already used some API requests, e.g. loading caches in Live, viewing an individual cache etc. that could have caused it to appear.

Since Cachly 4, I'm no longer receiving the waiting message when updating (pretty much) the same set of caches — so it's definitely slower 

FWIW, I deleted and reinstalled Cachly, redownloaded My Finds, and same crash occurs.

Have e-mailed that log too.

Should it start with Cachly?  The only ones I can see are Cachly.cpu_resource… I've just e-mailed the latest of those.  The timestamp looks around the start of the update rather than when Cachly crashed though.

BTW it's actually significantly slower now:  I wasn't timing but it's gone from 5-10 mins to 30-40 (before it crashes).