pppingme

These options are "AND"... So checking the I Haven't Found should never return anything thats been found.. My thought would be that (its been stated before, don't know if its still true) that the PQ's run off a backup of the main database and if the caches were very recently found, that may not be reflected in the backup database. Remember here about two or three months ago that PQ's weren't returning new caches?? Same type of problem.

If its working fine, then can you explain why selecting multiple attributes would return MORE than selecting NO attributes?? In any case, selecting NO attributes should return the maximum number of caches, however, selecting multiple attributes (setting aside the OR vs AND argument) should always return fewer (unless all the caches just happen to have the selected attributes, unlikely, but still would never return more).

Setup a PQ, you don't have to run it, just preview it... Think of PQ's as an advanced filter... By the way, there are issues when selecting multiple attributes...

Then explain how selecting multiple attributes returns MORE than selecting no attributes... Its broken...

How old are the finds??

Go and actually count the results, don't depend on the counts it tells you at top of the listing and don't just count the number of pages it returns, count the actual number of caches... There are NOT 78. Using attributes in PQ's is very very buggy and has been discusses many times. Selecting a single attributed seems to work most of the time, but multiple attributes has never worked that I know of.

At the bottom of the PQ list, there is a box labeled the "My Finds"... There is a "Add to Queue" button in it... You must of hit it (by accident). I wish these auto-generated, but they don't.

Really? Yes, Really... This agreement is calling YOU the licensee, and this agreement applies to ALL premium members, therefore by this agreement your allowed to share .gpx files (and derivatives of them, ie gsak exports) with any other premium members. This "may" apply to non-premium members too, I haven't researched enough. Also, the question could come up if gc.com has the right to limit the distribution of this data as it is NOT their original work, it belongs to the cache owner. Unless the cache owner specifically grants gc.com those rights, then gc.com may not even have the right to limit distributions of it. I believe that most cache owners feel that they are putting the information into the public domain by listing it (without copyright notices) on a site that most people perceive as a public site.

Both of these are easily doable with PQ's. Remember, PQ's aren't just for getting bulk data. They are good for advanced filters as well. I have a handful of PQ's similar to these and use them when I'm looking for caches. One option is to only show caches hidden in the last 7 days, another is the last month. You can also filter on just premium caches. Don't schedule them to run (unless you want to), but click on the link on the far left, you'll get the results of the filter just like any other cache listing.

That's really expensive in terms of database queries because there's no reasonable upper bound to the number of iterations. I don't think we'll ever get this behavior. This behavior is what Raine and others have documented right here in this forum, and from my testing, seems true...

I thought about this too. For this particular cache it has a small TB history, so that was easy to eliminate (unless people are deleting their TB logs as well??). As far as other reasons for deleting logs, I've had other caches that I just happen to have on my watchlist also show up as "changed in last 7 days", so I would expect to have seen an email on those, and I haven't. I've also wondered if adding/removing from either a bookmark or my watchlist would cause the cache to be "changed", so I tried both and neither seems to do it.

What does "Updated in the last 7 days" mean in a PQ? I understand it to mean: 1-Something got logged (find, dnf, note, etc) 2-Owner updated the page somehow Is there anything else? I have one PQ with this option selected and I think I'm getting caches back that I shouldn't be getting. For example: http://www.geocaching.com/seek/cache_detai...b1-814cd8c96f9b Last log is about 3 weeks ago, and owner hasn't logged in for a month. So, why did I get this cache? I get a LOT more than just this. I would say that approximately 25% of the results don't seem to fit the criteria (no recent logs, and highly unlikely the owner has made a change). Any ideas?

Your arguments are valid (and I agree 100%). This seems to be more of a political issue and not a technical issue. Your right that increasing the limit to 1000 would put very little "extra" stress on the site and in other posts it has been clearly stated that bandwidth is not an issue (the 2nd argument against an increase). Anyone who understands basic database concepts can understand this (those who argue otherwise don't have these concepts). This has been asked for MANY times and the requests just seem to be ignored by everyone except the users. If (and I'm not saying which way I think it swings here) it does cause an excess load to the servers, then that is a very basic and fundamental design issue to the site and shows extremely low skill in running a site of this magnitude, or any site that depends on data on the back end for that matter. Look at the performance of the site for the past couple weeks and see if you think that applies to this statement...

Most likely the problem is this: http://forums.Groundspeak.com/GC/index.php...24&hl=reply Anytime you send email to another user and "DON'T" hide your email address, you have the potential to hit this issue. GC sends out email from other users in a way that most ISP's identify (and yes, they should) as spam. This is an easy fix for gc to fix, but as far as I can tell they don't even want to acknowledge the problem. IF you "hide" your email address when you send those notes, the email will most likely make it through..

removed double post...

My guess is that this is more of a fluke and not part of the problem. One thing that I can think of is size... Are you zip'ing up your PQ's?? From what I've seen, on average a maxed out PQ (500 results) zipped comes through at about 3-500K (about 1/2 meg). Unzipped PQ's can easily be over a meg, about 1.5 meg from what I've seen. As archaic as it may seem, I still see ISP's filter/drop/bounce emails that are over 1 meg.

Ignoring the count at the top of the results, look closer, do you really see 500 results?? (page through them). Now that aside, excluded attributes is VERY BUGGY, and does not work correctly... http://forums.Groundspeak.com/GC/index.php...ributes+exclude

These coords seem to point to some uninhabited place around china??? Nearest cache to those coords is 149 miles away... I'm guessing (anyone want to verify) that the default query won't return anything further than either 50 or 100 miles... http://www.geocaching.com/seek/nearest.asp...;submit8=Search Perhaps you mean: 30 50.035 -083 58.416 (note the negative notation) That would put it in Georgia... Near where you live perhaps??

These would be valid arguments IF (and only if) this were a hobby board or something. The fact is, this is supposed to be a business run by about a dozen paid people. The real fact is, there is a weakness. They don't know how to scale the site, and it shows. This is not a dollar issue, but rather a skill set issue. Until they get someone in there with the right skill sets, this problem is only going to get worse. Unfortunately, people go out and learn how to code a few .asp pages, and think they know how to run a server, and when things get slow, they just throw more hardware at the problem. This isn't the way it works. There are obvious weaknesses in how the servers are setup, and they keep wanting to throw programming at it (remember the slowness a couple weeks ago was blamed on the weekly emails?? something thats been running fine for a couple years?). Until they get someone in there that understands these things at a server level, and understands what it takes to scale a site, this is not only going to keep happening, its going to get worse.

I suggest posting a message at: http://mogeo.ipbhost.com Very active group in that area..

If your looking for FTF opportunities, then dates don't matter (to the extent that recently approved caches are your goal). Setup a PQ, use your home coord's or zip code as a center point and the only other thing to select is an option (forget exact phrasing) "That haven't been found". This will give you all caches that don't have any finds logged against them.

If you go to the "Hide and Seek" page, and select by state, it shows all the caches in your state, sorted by date, newest first. Personally, for mass sorting and filtering and stuff like that I much prefer to have the caches offline and use a program like GSAK.

When I run a PQ with "Updated in the last 7 days", I seem to get more caches than I should. For example: http://www.geocaching.com/seek/cache_detai...7d-459bf39e48d7 is returned. At the moment I looked at the pq results, this cache was listed, looking at the listing, it has neither any logs in the last 7 days, nor has the owner logged in during that time frame. I see a lot of other results that don't have logs in the last 7 days, but the owner has logged in, so I give the slight possibility that the owner made some minor change. Either way, I seem to be getting results that I shouldn't be. Am I not understanding what I should be getting, or am I missing something? The results that I expect, based on The Leprechauns explanation is anything that has any type of log entry in the past 7 days OR anything that has been changed, edited, etc (probably by the owner) in the last 7 days. Is there another condition that would cause more caches to be returned?

Because if I'm watching a cache, I'm probably interested in ALL aspects of that particular cache. I've seen a lot of caches get disabled, then re-enabled when they probably shouldn't have (still in bad shape). If on the other hand someone else adopts the cache, then there's a good chance that the cache has (at least for now) been maintained and brought up to a better standard. I add caches to my watch list when they are probably a cache I want to visit (or that I have dnf'd), but based on the logs don't sound like they are up to par. I watch them and then try to find them when I think they have been returned back to par. In this case, knowing an adoption happened is usually a good thing.

Currently when a cache is "adopted", there are no log entries generated, nor are users who have that cache on their watchlist notified. This is a feature request for when caches are adopted that a log entry gets generated and users who have it on their watchlist get notified.