ak8b

Well, it seems to be mostly done. It's NOT totally self healing. Those caches that don't get included in the PQ after things are reset don't get fixed. Not really a problem though, just an annoyance. This could certainly have been handled better. The method looked like the 'quickest' way rather than the 'right' way.

Hopefully they'll make it work properly when they're done ...

Recently, maybe 10 or so days ago, pocket queries started including the addition of text listing child waypoint data appended to the end of the long description text. It only shows up in GPX files, either by pocket query or from the "GPX" button on a listing so it appears to be something to do with the GPX generation code. This is also causing quite a few caches to be included in pocket queries that specify "Changed in last 7 days". It kind of looks like some sort of debug code was left in the production version. I've checked with a fellow geocacher and he is seeing the same thing.

That article doesn't really provide much useful information. It's not clear that the actual running of PQs should be affected. The "problem" has been ongoing for close to a full day now.

Same here. Of the four I ran today only one, which is the only one larger than 500 results, is in the download section. Are we not putting ALL PQs in the download anymore?

Not working here either. After yesterday's really late scheduled PQs I'm not particularly surprised. I had the impression that the database server upgrade was supposed to make things better. It's been worse instead.

It is working strangely. I did NOT press the button and I got one this morning - only 6 days since the last one ran.

It's getting even stranger ... Last Saturday (8/30) I was mashing the button and getting nothing. I just gave up and moved on to other things. Last Sunday (8/31) there was a My Finds PQ in my email that had run at 12:48 AM PDT. Today, Saturday (9/6), which is only 6 days, the My Finds PQ was in my email and ran at 12:50 AM PDT. The odd part is that I never requested, or even had the chance to request, the PQ.

Today I got the three PQs that should have run yesterday. I'm thinking the scheduler machine has the wrong date? If so they REALLY need to set up something to prevent this. It's something I never even have to think about on a Linux machine.

Be sure to uncheck your regularly-scheduled Pocket Queries after creating the copies. You will get that error message if you have more than five PQs checked for a given day regardless of whether or not any have actually run. I tried that - didn't make any difference. It said I had already RUN 5 PQs that day.

Same problem here - I have three that should have run but didn't. I copied all three and then started checking them off. First one OK (and ran right away), Second one OK, Third one says "You already ran your 5". No I didn't! I think the scheduling process tagged me as having run it but the actual process didn't complete so no PQ data. Since they run now I suspect that whatever was broke is OK now but this issue still needs to be addressed. Not fair to "charge" me for something I never got.

I would hardly call the dozen or so people in this thread a "majority" Add all the threads about this subject together and you've got maybe 150 complainers. Not even close to a majority compared to the 46,740 cachers who submitted logs last week. The term I would use is "vocal minority" Actually the majority of people I cache with, those who have thousands of finds each, seem to get along just fine with the system the way it is. Every time this thread comes up, it's mostly newbies who are asking for all these new features. Those that have been around know it ain't going to happen and they work with the existing system. I thought that this WAS the place to ask for new features and to discuss alternatives. Just because it's been shot down before doesn't mean it shouldn't be reconsidered from time to time. It's an ENHANCEMENT. Nobody would have to change the way they're doing things now. When the PDA had 4 MB of RAM it made sense to only load what you were going to hunt for the day. Since they now have MUCH more it's pretty convenient to have everything for the surrounding area. I travel around going to customers and may get an opportunity to cache in any area at any time and running a specialized PQ every day for where I think I'm going (it can change) just doesn't work. There is nothing worse than looking for a cache that has been archived and with a seemingly simple extension of the existing facilities things could be kept up to date easily. Enough said. Those of you who think this is a dead horse can go flame some other thread. Those with something constructive to say should stick around.

I can't believe how stubborn some people are. Every other part of this is completely automatic. It's just this one thing that isn't. Manual processes are stupid and have NO PLACE in the world of automation that GSAK can provide. GSAK is getting close to being able to automate this. If the new functionality of "Check Status" was made available as a function in a macro I could easily write a macro that would be able to automatically clean out the garbage. Not quite as nice as Groundspeak actually providing the data but better than going through your "not found, no GPX in the last 10 days" list and manually checking them all. And just how much busier would the Groundspeak servers be if it weren't for the offline GSAK databases? I believe that GSAK is taking a significant load off of their servers and they should be happy to support it.