ChriBli

Seems to be working again, maybe just a glitch. Phew.

It was working fine just hours ago! Now it's not. I still have a browse map open, it shows caches and continues to do so even if I pan and zoom it, but all the caches are marked as unfound. If I open a new browse map in either Chrome or Firefox it's empty. I'm not closing that working tab....

Yes, and I assume if I check your finds or hides archived are also missing. When I check my own finds using the new "search" rather than the old, reliable list I also see 4044 now, that is archived missing. That seems to go on and off, but since that method is persistantly flawed by showing only 1,000 finds, I never use it.

I don't know exactly how you go about this. When I go to my profile and click Geocaches (Yours) I see all my hides, including the only archived one (an event). The page I end up at is https://www.geocaching.com/my/owned.aspx.

https://www.geocaching.com/seek/nearest.aspx?u=Crescent Trekkers&ex=0&cFilter=69eb8534-b718-4b35-ae3c-a856a55b0874-parent&children=y shows you at least your last 20 events. Seems to be some problem going to page two.

Makes sense, kind of. I did log using two different methods, phone/app and computer/browser. Of the ones logged by phone, two were later edited on computer, and two were deleted and logged again, also on computer. This can not fully explain the behavior, but I think I'll risk deleting all eight logs and then posting them again. I have a hunch this will cause issues with FP earnings, but I'll rather have that than unordered logs.

A couple of days ago, I found eight caches in one day, all but one traditional. This is the order in which I found them, last on top: #8 Björkbackaslingan - Kattåsen #7 Björkbackaslingan - Ludvigsro #6 Björkbackaslingan - Promenaden #5 Björkbackaslingan - Enebuskar #4 Björkbackaslingan - Åsen #3 Björkbackaslingan - Grustaget #2 Lillsjöbacken #1 Knack, Knack. However, the last six of them were published on that date and I was FTF on the first two and the last two of those. I therefore logged #1 and #2 online first, before the new six were published. Then I made short FTF logs for #3 and #4, didn't bother with #5 and #6, and again posted FTF logs for #7 and #8 from my phone. In the evening, I edited the logs for #3 and #4, deleted the logs for #7 and #8, wrote new logs for #5 and #6 and finally re-logged #7 and #8. All with the intention of getting the online logs in order while at the same time posting FTF logs as soon as possible. This did not work well. In "your logs (last 30 days)" it looks like this. The same incorrect order in both old and new find listings. It is hard to understand how #3 and #4 could end up as the last two found, since I did not touch those online logs after writing logs for #5 and #6 and re-posting logs for #7 and #8. Even stranger, if I look at "dashboard -> your geocaching logs" the order is the same as above except that the two last are now the two first! So even before the logs that were written before the last six caches were published. Is this some kind of new behavior? I have never seen it before, and I have on occasion deleted logs and re-posted them to get the order right. More importantly, do I dare to remove all eight logs and re-post them, or will I mess up things completely? I really want my online logs in the right order.

...the horror......the horror...

Yay! Great news!

The next phone will take even larger images! I doubt anyone buys a new phone just because the memory got full. I think it is entirely possible that some people want to utilize the resolution that was stated in the spec sheet when they bought their phone.

This just happened to me too. In English rather than Czech, but otherwise exactly the same. Copied the log test and went back to the cache listing to see if it had been posted anyway, but it had not. Tried to post again, and then it worked. Latest Brave browser. This was an OM log, in case that matters.

Not new, or at least it was that way in the "opt out" logging. I.e. you could add name and description, don't remember if it was encouraged to the same degree.

About that, what is actually the point of the preview window? Just like when I'm writing this, there is a toolbar containing all the formatting I can think of (all that's described in "how to format"). Yet no preview is needed here? Any formatting I'm doing here is visible directly in the editing window, or I'm editing in the preview if you will. Especially for those who like me use formatting sparingly, the preview window functions only as a guarantee that I will have to scroll down to get to the post button. I do realize that this functionality may be bought from elsewhere, and that it was the same in the good old old logging, and that there is an option to hide the preview now. Still, I have to scroll down. This is what the bottom of my screen looks like now, with collapsed preview window. A post button could easily have fit there.

Funny, that used to work without the little pin before.

Well illustrates the consequences of changing things that work perfectly fine. But OK, then I understand. The reason for going back to the old way is to stop people who don't want to write something that makes sense in a known language from posting OAR/RAR at all.

Hmmm, I wrote a reply without being logged in and it went poof. Not sure if it will be posted after approval. Anyway, the point of it was: How could this force anyone to write OAR/RAR logs that make sense, or to do it in English? What's to stop anyone from leaving that field blank?

I don't know.. there was no (practical) limit before, was there? Storage cost x image size produced by consumer equipment should stay fairly constant, I believe. Automatic resizing was already done, but just to store an extra low-resolution copy. Why could it not be done also on the stored "original", if that is over some arbitrary limit in size? That to me would be the best option, with doing away with storing the original at all as a distant second. Limiting the size in the camera app assumes that you know that all your photos are intended for this purpose, or that you are willing to sacrifice the high resolution of your expensive new phone for all your photos.

It does not work with Firefox 86.0.1 either. It does work with the latest version of Brave, probably with the latest version of anything. I don't think anyone bothered to compile any system requirements.

I see now that this is the link that you could use to see the full find history, including archived, for yourself or someone else. Something akin to a basic human right and necessary for many puzzles, if nothing else. This link was thrown around to quench most of the critcism of the decision to limit this history to 1,000 finds (the reason for which was never revealed) - look, you can still see your finds using this link. Well, now you can't.

So what is the limitation good for, then?

It's not called "binned" anymore. It's called "streamlined".

I've seen people asking for this, but the reason is usually to prevent newbies from posting found when they didn't find. As if that would matter much. Personally I log at least twenty found between each DNF or WN and it is of course tedious to have to select it for every log. Forgetting to change to DNF has happened to me too, as has choosing the wrong date, but if you realize your mistake you just have to correct it. But all of these little issues pale in comparison to the fact that there is no reasonable way to upload log photos as taken with a modern phone or camera anymore, for the first time in two decades. That is a showstopper.

To me, this is a no-brainer. If I were to decide how to implement a limit, I would not even consider another approach unless there were any really difficult technical problems with resizing images - and we know there isn't since there is a 640 x 480 px copy made already today. As I mentioned before, until recently I thought that this was all that remained of an uploaded picture, and I was fine (sort of) with that. I suspect the vast majority of cachers never look at the hi-res version of any log photos. Imagine the storage that could be saved! A 640 x 480 picture is maybe 150 kB. But having to do the resizing yourself is a major issue, and something that will affect almost everyone (that uploads pictures at all). The very small fraction of cachers that post to this forum seem to have various procedures set up already to downsize or otherwise adjust their images, but I'm willing to bet that the most common case is that you snap a photo with your phone, not having decided yet whether or not this is to be uploaded with a log or used for something different, and when you decide to upload it you want to just drop it there. Not launch another program or app, do a lot of fiddling and then save the file in another location, upload from there and then have a bunch of files left on your disk. So, the question is, why can not an uploaded image be automatically downsized/recompressed at least if it exceeds 5 MB? Note that this would not mess anything up for anyone that is already in the habit of doing this manually for one reason or another.

I stand corrected, the first 17 years. But not really, people opting out could still post many photos, and anyone wanting to post many photos could opt out. So the effect on number of uploaded photos should have been marginal during the last six years. I certainly opted out, because I prefer working things to stay unchanged, so I never noticed the 20 image limit. It is listed in the release notes right next to the 5 MB limit, was that also a property of the new logging page from 2017? I wonder what percentage of users opted out, I guess we'll never know...

Are you likening log photos to garbage? Why not remove them altogether then? I also think 20 photos would be enough in most cases, I for one have maybe a third of a photo per log on average. But no (practical) limit has been needed for the first 23 years of this game (I am aware that log photos may not have been a thing for the first years), so why now.