abra123cadabra

I'm following the main definition of DNF. Using the Cacheberry app, I always put add a fieldnote to any cache I've tried. Uploading them to GC is very easy. It's very disappointing to log a DNF when all others found the cache "easily". Some would state their number of attempts but just looking at the cache page makes a cache look like it's quick and easy whereas in reality it might not be so. A cache page with several DNFs hints to me that the container might be unusual so I start thinking outside the box instead of looking for the standard container for that given location. Another problem are cache pages for difficult caches which have no DNFs because the CO deleted them. Overall I would prefer more people to log either a DNF after a serious effort to find a cache or at least to post a note why they abandoned. Like this it's much easier to decide if I want to go for this specific cache or not. abra

That's good to know. So the maintenance has been logged to get rid of the "needs maintenance" icon. But why delete it afterwards and thus taking away the information that the cache is still there (if indeed the maintenance has been performed and the cache is in place, which I doubt)? abra

Today I received two notifications that a log has been added to a cache on one of my bookmark lists. The first one was a "needs maintenance" log as the cache hasn't been found in more than a year (D1/T1). The second was a "performed maintenance" log stating: "Cache checked yesterday and is in place". Following the link in the notification to the maintenance log, I get the following error: "You cannot read archived log entries." and this log is also missing on the cache page. Is there an option for the CO to archive logs (own and those of others) or can he only delete logs? When a log is deleted, would I see the same error message (if I followed the link in the email)? Posting a maintenance log and then archiving/deleting it got rid of the "needs maintenance" icon on the cache listing but what I don't understand is why the CO would not want other cachers to see the confirmation that the cache is still there. There is at least one more cache by the same CO that is missing DNFs. No visible maintenance logs, never found since placed in September 2007 and only 6 notes and 1 DNF. The story is very interesting and I have the confirmation from the cacher with the only DNF that his previously logged DNFs have been deleted without explanation. Granted, it's a D5/T5 rated multi but the starting point is in an urban area so I would expect to see more logs. I logged a DNF and "needs maintenance" on another cache (D1.5/T1.5) not found for more than a year politely asking the same CO to check if the container indeed is in place. My "needs maintenance" was deleted and a note posted that the cache is still there. Read through ALL previous logs and searched again without success. I seriously doubt that the container is still in place but will contact a previous finder on this one. Overall I am not sure if the logs for caches owned by this CO are "complete" and I seriously doubt that some of them are really still in place despite a note that they are. Anyone got a similar experience or an explanation for this behaviour? abra

Yes, it's a very trivial fix and something that should have been caught while testing the code. It's extremely frustrating that releases get pushed live before a long weekend leaving people with limited ability to use their premium member features. I paid to get those features so please don't break them when they will be needed the most. If the code is not ready, then postpone the release. abra

Quick update: I have modified my other 1k PQs and were able to download. It must be the "use query name" that breaks it. Without this option ticked it's fine. Also, with or without "send as zip" it's always a zip. As long as the PQ name is used in the download tab I'm fine as I'm loading them immediately into GSAK but if I were to save the files I would prefer to have the name in it, so please do fix this bug. The other bug in maps preview happens to me too: 1 odd cache on a different continent. I also noted that the maps are extremely slow to load. And yes, I also have a big difference between caches in maps view vs list view. abra

BUG It's been mentioned in this thread before. I have merged my 500 cache PQs into 1k PQs yesterday, then I deleted the old PQs but as before they appear striked-through and will hopefully disappear after their 24 hour since last run is over (one already did and the first 1k PQ ran for wich I received an email notification). I also saw that those old PQs where available for download but clicking on the link just made the link disappear one by one without the zip file being downloaded. The error message said the query didn't exist any more so I thought it's because I deleted those queries. Today I clicked on the link for the first 1k PQ in the download tab and it happened again. The link disappeared, no file downloaded. The error message is: Sorry, the requested Pocket Query download is no longer available. Now this is extremely annoying and definitely not connected with the original query being deleted. I didn't make any changes to it since it ran. Just received the notification for the second PQ. Guess what, the same happened. Link gone, no download, same error message. Here is the link (copied before it disappeared): http://www.geocaching.com/pocket/downloadp...ba-adbac7125fe7 My PQs are named like this: All_Ireland_1:_01-01-2000_to_29-02-2008. I thought this should be ok. The settings are to include the name and to send as a zip. I hope this helps and this bug is fixed soon. It is most inconvenient as I was just getting ready to use the bank holiday for some serious caching but now I cannot even update my GPS, not to mention GSAK. abra