ChriBli
-
Posts
398 -
Joined
-
Last visited
Posts posted by ChriBli
-
-
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....
-
12 minutes ago, SW00P said:
When I check your finds 4044 and hides I get 10. Archived missing. Chribli account I checked.
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.
-
30 minutes ago, Crescent Trekkers said:
ChriBili,
Thanks for this information as it will solve my immediate issue. I still can't see any of my archived caches when setting the filters as I mentioned above. Did you find the same choices for cache status as I did?
Frank
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.
-
9 minutes ago, Crescent Trekkers said:
I was trying to find some of my archived events using the information via my profile. The only cache status available were All, Enabled Caches, Disabled Caches. There is no option to include Archived caches. I set my filter at All, but cannot view past, archived events. Any help will be appreciated. I have always been able to do this in the past but not today.
shows you at least your last 20 events. Seems to be some problem going to page two.
-
20 hours ago, ivss_xx said:
Were all the logs posted via the same method? (website/app/gsak etc) I can't remember exactly what was the issue but I think it is known that logs submitted via different means can have a different timestamp in the GC database. Someone can elaborate or correct me if I'm wrong.
Personally, I also like my logs to appear in the correct order, but I really care only for big milestones.
I also always add exact time of find and a counter to my logs, so the list order is not that important if I need to go back to years old logs to figure out what was the exact order of caches I found on a day.
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.
-
.png)
1
-
.png)
1
-
-
1 hour ago, MNTA said:
Would love it if Groundspeak would purchase project-gc
...the horror......the horror...
-
1
-
-
1 hour ago, Oceansazul said:
We are working to increase the photo limit to 10 MiB, from 5. We hope to have that fix out by the end of this week.
Yay! Great news!
-
7 hours ago, arisoft said:
I suggest you to give a try if your FWIW phone is compatible with this https://play.google.com/store/apps/details?id=net.sourceforge.opencamera&hl=en_US
The default app in my phone is making about 4.5 MB images (no way to adjust) but I am completely satisfied with about 0.5 MB images I take with this app.
The idea of making too large image files is just to keep you buying the next FWIW branded phone.
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.
-
3
-
1
-
-
On 11/19/2023 at 8:43 PM, Solim said:
I have a logging problem.
I use Firefox. I write the log and I get a gum when sending:Failed to send the logo
Something was not going well. Stay on this page to maintain the text of the logo and try to send it later.
Failed to send the logo
Something was not going well. Stay on this page to maintain the text of the logo and try to send it later.It is twice the same, I will wait to send and get the same answer (I try it 20 times and still nothing).
Only a new page load (Ctrl+R) will help, then you can send.
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.
-
3 hours ago, Viajero Perdido said:
I like the new (it's new, right?) encouragement to add name and description to photos.
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.
-
1
-
-
On 11/17/2023 at 10:31 PM, baer2006 said:
I can confirm this bug, and it's quite annoying. The whole point of the preview window is to see, if your formatting really does, what you think it does - especially in situations, where punctuation might get in the way of "markdown" symbols.
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.
-
1
-
1
-
-
5 hours ago, Tundra Wolf said:
Not a bug. There is a little pin above the date. Click that to set the date as "sticky". In other words if you do that then as long as the browser session stays open, the date will be the same on each log (whatever date you set) until you change it manually, or until you unclick that pin.
Funny, that used to work without the little pin before.
-
1
-
2
-
-
20 hours ago, Pleu said:
If people bother to make a separate OAR/RAR-log they usually bother to include the reason of the log. It worked perfectly fine for years before the automatic versions were introduced.
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.
-
1
-
-
2 hours ago, Pleu said:
These were two separate logs for many, many years before the "all in one"-solution that you like was introduced. As a CO I hate the automatic NM-log in the players language so much because it's a standard log that tells me nothing about the issue and half the time it's in a language I don't even understand since some of my caches are in tourist-y locations. Forcing the player to write a OAR-log that actually makes sense is a big improvement. Specially since one of the standard options was often read by newbies as "this makes sense to click anytime I can't find a cache" which actually caused a lot of extra work for COs for no reason.
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?
-
1
-
-
2 hours ago, arisoft said:
And even bigger - 50 MB for example.... there must be a rational limit for those images. Automatic resizing at the client side would be the second best option after the best option, which is to limit the size in the camera app. It is pity that some basic smartphones does not have this option.
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.
-
2
-
1
-
-
31 minutes ago, Nylimb said:
Does anyone know what the system requirements are for the new logging flow? I have an old computer, running Mac OS X 10.11 and Firefox version 78.15.0esr (64-bit), and when I try to log anything I get a blank window. If I knew what version of Firefox the new logging flow requires then maybe I could check to see if my hardware is capable of running it.
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.
-
3
-
-
7 hours ago, Boomshanka said:
It looks like this page has been binned as part of the upgrade. I used to like seeing when caches I've found have been found recently... can it be reinstated?
https://www.geocaching.com/seek/nearest.aspx?ul=BoomshankaI 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.
-
7
-
-
11 minutes ago, monsterbox said:
Simply add as many notes as you need. That's an easy to overcome limitation, isn't it?
So what is the limitation good for, then?
-
1
-
-
54 minutes ago, Boomshanka said:
It looks like this page has been binned as part of the upgrade. I used to like seeing when caches I've found have been found recently... can it be reinstated?
https://www.geocaching.com/seek/nearest.aspx?ul=BoomshankaIt's not called "binned" anymore. It's called "streamlined".
-
1 hour ago, barefootjeff said:
Please no. There were way too many intended DNFs and WNs being posted as Finds because the logger forgot to change the default type. I got caught out a few times when intending to post a note on a cache I was planning to attempt, only to be focused on what I was writing and realising a second after posting it that I forgot to change the log type from the default.
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.
-
2
-
-
3 hours ago, kamla said:
I don't have any issue with a size limit - but I wonder about the way it's implemented. Instead of enforcing a size limit and forcing the user to resize the image to be below the 5MB limit why don't you resize the image on upload? This can easily be done on the client with a few lines of javascript (keyword canvas) and is what's commonly used.
That'd be the most user-friendly solution as the user can use 'any' input and would allow GC to still enforce its limits.
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.
-
4
-
2
-
.png)
2
-
-
12 hours ago, barefootjeff said:
The "new" logging page that was introduced in 2017, which I guess you opted out of, limits the number of photos that can be added to a log to twenty. I'm guessing the same coding under the hood is responsible for the limit in this new version.
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...
-
1
-
-
7 hours ago, JL_HSTRE said:
Much like the erection of a sign reading "No Dumping" on a vacant lot, Groundspeak giving notice that they were setting a 20 photos per log limit seems to me the kind of thing that shouldn't need to be explicitly stated in the first place.
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.
.png)
.png)
.png)
No caches shown
in General geocaching topics
Posted
Seems to be working again, maybe just a glitch. Phew.