Jump to content

Pocket Queries


LHollo777

Recommended Posts

Oh where, oh where could my pocket queries be? Oh where could they be?

 

is it just me? I seem to be waiting a long time for my pocket queries to arrive. I don't have a problem paying for a premium membership but I really would like to receive the "perks" as advertised that come along with it. Pocket Queries have always been somewhat problematic but it seems the problem is escalating lately. I realize it is still early on the left coast but I'd like to get them a little earlier in the day here. Oh, well, just venting! Thanks for listening. :rolleyes:

Link to comment

Oh where, oh where could my pocket queries be? Oh where could they be?

 

is it just me? I seem to be waiting a long time for my pocket queries to arrive. I don't have a problem paying for a premium membership but I really would like to receive the "perks" as advertised that come along with it. Pocket Queries have always been somewhat problematic but it seems the problem is escalating lately. I realize it is still early on the left coast but I'd like to get them a little earlier in the day here. Oh, well, just venting! Thanks for listening. :rolleyes:

 

They've been running fine for me.

 

What email provider are you using?

Link to comment

ok, so here we are, Saturday AM, even on the left coast, and only 3 of my 4 scheduled PQs for Friday have arrived. Of course, the most important one didn't even run at all. Perhaps it is time to reformat the way PQs are run. I understand that the servers are overworked on Fridays and Saturdays but IMHO it is time for a revamping of the system if I can't receive one of the benefits of a Premium membership, no? As we travel hours and hundreds of miles to cache, we really need more than a 500 cache radius. Perhaps one query of 2000 would take less time and free up the server quicker than 4 queries of 500 each? Perhaps there could be an "obssessed-cacher super-duper premium membership" for us server-resource hogs, lol. :rolleyes:

 

Other than no longer being able to easily research archived caches and this Pocket Query issue, the geocaching website is wonderful resource. :unsure:

Edited by LHollo777
Link to comment

It seems new PQs have priority over scheduled PQs. That seems backwards. So if you want a PQ done on time, don't schedule it. Run a new one. Of course that's gonna lead to more backlog. It's a vicious cycle.

 

My PQs aren't running either. ;)

 

Same thing happened last week. Week before too. What the heck? :anibad:

Link to comment

It seems new PQs have priority over scheduled PQs. That seems backwards. So if you want a PQ done on time, don't schedule it. Run a new one. Of course that's gonna lead to more backlog. It's a vicious cycle.

I think it makes perfect sense to give the highest priority new PQs and the lowest to those that run every day.

  1. If you are running a scheduled PQ you should have one from the last time you ran it. The people who run every day have yesterday's results to fall back to. If you schedule your PQ for once a week you have data that is only one week old. If you never ran the PQ you have nothing to fall back to. So I would hope that would get the highest priority.
  2. TPTB allow you to run up to 5 PQs a day, but they anticipate that not everyone will run all five. The intent was for people to run just the PQs that you are going to use. Some people are running a lot of PQs every week or more often in order to maintain an offline database. TPTB have stated that this was not what they intend for PQs to be used for. By given low priority to scheduled PQs and high priority to PQs that are created on demand for one time use they are encouraging PQs to be used as they are intended.

That said, it is true that someone who runs a weekly PQ could simple make a new copy of it every week and it would go the front of the queue. This means that people who don't copy their PQs and just leave them in the queue will see their PQ run later and later each week. TPTB probably feel that the people who make a copy are more likely doing so because it is important to them to get that PQ on time. So they get bumped in priority at the expense of the people who just leave the old PQ running each week.

Link to comment

I created a new PQ on Wednesday and scheduled it to run on Thursday for the first time. I would have expected it to run shortly after midnight, assuming the new PQ's get priority. However, it ran almost 2 hours after midnight.

 

I doubt there are 2 hours worth of new PQ's to run first thing on any given morning.

Link to comment

I created a new PQ on Wednesday and scheduled it to run on Thursday for the first time. I would have expected it to run shortly after midnight, assuming the new PQ's get priority. However, it ran almost 2 hours after midnight.

 

I doubt there are 2 hours worth of new PQ's to run first thing on any given morning.

"Midnight" in Seattle or "midnight" in your part of Ontario? The pocket query servers use Groundspeak's timezone. I am in the Eastern timezone. My never-run queries run shortly after 3:00 a.m., eastern time.

Link to comment

I created a new PQ on Wednesday and scheduled it to run on Thursday for the first time. I would have expected it to run shortly after midnight, assuming the new PQ's get priority. However, it ran almost 2 hours after midnight.

 

I doubt there are 2 hours worth of new PQ's to run first thing on any given morning.

"Midnight" in Seattle or "midnight" in your part of Ontario? The pocket query servers use Groundspeak's timezone. I am in the Eastern timezone. My never-run queries run shortly after 3:00 a.m., eastern time.

 

I took that into account. My PQ arrived at 5:00 a.m.

Link to comment

I created a new PQ on Wednesday and scheduled it to run on Thursday for the first time. I would have expected it to run shortly after midnight, assuming the new PQ's get priority. However, it ran almost 2 hours after midnight.

 

I doubt there are 2 hours worth of new PQ's to run first thing on any given morning.

"Midnight" in Seattle or "midnight" in your part of Ontario? The pocket query servers use Groundspeak's timezone. I am in the Eastern timezone. My never-run queries run shortly after 3:00 a.m., eastern time.

 

I took that into account. My PQ arrived at 5:00 a.m.

Were you at your computer waiting for it at midnight...or 2am/3am as the case may be...or are you just looking for something else to be unhappy about?

 

Why not just create it on Thursday morning to run immediately and get it within a few minutes?

Link to comment

Perhaps he wanted to be sure he had it as soon as possible on Thursday and not take a chance on some unexpected delay.

 

I don't see Tequila as looking for something to complain about, but offering another data point in our understanding of how PQs are run.

 

If Groundspeak would give us a display that showed the date/time last run of the current PQ being processed, we wouldn't spend so much time trying to figure out what the "black box" is doing.

 

(My Thursday PQs ran at about the same time [7am] as they did the week before.)

Edited by beejay&esskay
Link to comment

One thing I wonder, is when someone doesn't get their scheduled PQ when they want it, and the make a copy to run right away, do they unschedule the previously scheduled one, or do they end up getting two copies of the same PQ? If they're getting both, this would explain a lot of the creep that you guys are seeing.

Link to comment
One thing I wonder, is when someone doesn't get their scheduled PQ when they want it, and the make a copy to run right away, do they unschedule the previously scheduled one, or do they end up getting two copies of the same PQ? If they're getting both, this would explain a lot of the creep that you guys are seeing.

 

I always unschedule the old one. That way, when I reschedule it for a week later, it is 2 weeks since it ran last and will probably run early morning.

 

There are things going on in that black box that we do not have the tools to understand.

 

For instance, my Thursday PQ ran at the following times in the last 4 weeks:

04:26, 08:20, 06:48, 06:50.

Something beyond "creep" was happening that second week.

Link to comment

I created a new PQ on Wednesday and scheduled it to run on Thursday for the first time. I would have expected it to run shortly after midnight, assuming the new PQ's get priority. However, it ran almost 2 hours after midnight.

 

I doubt there are 2 hours worth of new PQ's to run first thing on any given morning.

"Midnight" in Seattle or "midnight" in your part of Ontario? The pocket query servers use Groundspeak's timezone. I am in the Eastern timezone. My never-run queries run shortly after 3:00 a.m., eastern time.

 

I took that into account. My PQ arrived at 5:00 a.m.

Were you at your computer waiting for it at midnight...or 2am/3am as the case may be...or are you just looking for something else to be unhappy about?

 

Why not just create it on Thursday morning to run immediately and get it within a few minutes?

 

First of all, I wasn't complaining. I was making an observation on the process, and a discussion started by someone else.

 

As for creating it Thursday morning, your obsessed need to attempt to agitate, as opposed to contribute constructively to this discussion, blinded you to any number of reasons why a PQ might be created on Wednesday to run on Thursday.

 

In my case, I was recreating a regularly run Thursday PQ. Over the past 3 months the PQ started coming in progressively later each week. By creating it Wednesday for Thursday delivery, I was hoping to have it arrive immediately after midnight (as one would assume would happen with a new PQ) and therefore extend the number of weeks before the PQ would need to be recreated once again.

 

Feel free to attempt to agitate once again.

Link to comment

ok, so here we are, Saturday AM, even on the left coast, and only 3 of my 4 scheduled PQs for Friday have arrived. Of course, the most important one didn't even run at all. Perhaps it is time to reformat the way PQs are run. I understand that the servers are overworked on Fridays and Saturdays but IMHO it is time for a revamping of the system if I can't receive one of the benefits of a Premium membership, no? As we travel hours and hundreds of miles to cache, we really need more than a 500 cache radius. Perhaps one query of 2000 would take less time and free up the server quicker than 4 queries of 500 each? Perhaps there could be an "obssessed-cacher super-duper premium membership" for us server-resource hogs, lol. :)

 

I am wondering about the resources also....I would love to have the option of doing one large PQ rather than a bunch of small ones..And the people that wanted to do a bunch of small ones could have that option still available....Seems like a win/win! Great idea here IMO.

Link to comment

 

I am wondering about the resources also....I would love to have the option of doing one large PQ rather than a bunch of small ones..And the people that wanted to do a bunch of small ones could have that option still available....Seems like a win/win! Great idea here IMO.

 

I'm not sure one 2500 cache query runs significantly faster than 5 500 cache ones...

 

But as Raine points out in another thread, with their current goal of getting scheduled PQs done in the first 2 hours after midnight, this becomes moot.

 

(So I wouldn't expect TPTB to spend much effort in trying to figure an accounting system that would let you have a mixture of big and regular-sized PQs.)

Link to comment

I have the problem that scheduled Pocket Queries don't come in time in the past 2 months. Some times I don't get one PQ a week, then I get all of them on one day. A normal week should have 4 PQs Mon, Tue, Sat, Sun. But they are not sent correctly lately. I am not alone with this problem. Somebody else here who got this problem? I would really like that Groundspeak will get this issue solved as this is why I pay for their service.

Link to comment

I haven't run PQs for a month and then went to run one yesterday. If finally came in 6 hours later, but was only 10 caches when it should have been 200. This is frustrating. It has worked quickly and perfectly every other time I've used the PQ feature. Another vote to please get this straightened out sooner than later.

Thanks,

Mike

Link to comment

My scheduled PQ's have been running on time the past few days. And, any special ones that I've run have come back quickly.

One thing that get me when running the PQ's and Groundspeak's claim that the PQ's take a lot of resources to run... then how come I can preview a PQ on Google Maps immediatly, make a small change, and re-run the PQ. Shouldn't take that much more resources to run a regular PQ than a preview, right?

 

If the problem is that there is a greater load on the servers on weekends, they should look into some sort of cloud computing sharing resources with other organizations that have less load on the weekends. Works better that keeping all the resources on during slack times and then not having enough during busy times.

 

I scheduled a PQ that I had run on Sunday to re-run on Monday with a couple of parameters changed (forgot to update the dates). Didn't run at all on Monday, still waiting for it today. Meanwhile a PQ that I last ran a couple of months ago ran immediatly.

Link to comment

One thing that get me when running the PQ's and Groundspeak's claim that the PQ's take a lot of resources to run... then how come I can preview a PQ on Google Maps immediatly, make a small change, and re-run the PQ. Shouldn't take that much more resources to run a regular PQ than a preview, right?

...

 

No, that's not right. Previewing a PQ costs about as much as an advanced cache search. It's the generation of the .gpx file and packaging that into a .zip that takes resources.

 

I think it is a total volume issue as opposed to an individual PQ. In one of the threads Opinionate showed the number of caches that had run that day and how many more were in the queue. As I recall the number was around 40,000

 

Yep, close to 40k.

Link to comment
One thing that get me when running the PQ's and Groundspeak's claim that the PQ's take a lot of resources to run... then how come I can preview a PQ on Google Maps immediatly, make a small change, and re-run the PQ. Shouldn't take that much more resources to run a regular PQ than a preview, right?

Jeremy said it quite well back in 2006...

 

If the query runs well enough to generate a preview, why not just include a button to click in order to download the data in GPX format based on what the preview generated?
The preview is a table of contents. You want the whole book.

 

Using archaeic analogies of printers and pages, the previewing the results of the query vs. creating the whole GPX is similar to the processor either "printing a table of contents" or "printing the whole book".

Edited by Markwell
Link to comment

Using archaeic analogies of printers and pages, the previewing the results of the query vs. creating the whole GPX is similar to the processor either "printing a table of contents" or "printing the whole book".

 

Well, more like printing the index, as you have to calculate the relative distance between each cache and the centroid of the search area. If the search are contains more than the requested number of caches, you also have to rank the caches by distance.

 

From a database point of view, it would be interesting to see what information is indexed vs. just stored. I would imagine that the search criteria is indexed.

 

Packaging up the .gpx files, zipping them, and then emailing will take longer though, I'll give you that.

Link to comment

Scheduled PQs haven't run. I set them to run yesterday, Friday and nothing happened. Still, I made one from scratch and it ran instantly. I'm sure this will get fixed. :)

 

This is the same problem I've had for ages. Although I do not schedule any PQ's if I opt to rerun a saved PQ that has been run at any time in the last week or so, it just sits there checked to run. It has gotten to the point where if I want to run a PQ and receive it promptly, I have to either copy an existing one or create a new one.

 

Not knowing how the database handles all those archived PQ's, I would suspect that this isn't exactly a benefit to the database that generates the queries.

Link to comment

Scheduled PQs haven't run. I set them to run yesterday, Friday and nothing happened. Still, I made one from scratch and it ran instantly. I'm sure this will get fixed. :)

 

This is the same problem I've had for ages. Although I do not schedule any PQ's if I opt to rerun a saved PQ that has been run at any time in the last week or so, it just sits there checked to run. It has gotten to the point where if I want to run a PQ and receive it promptly, I have to either copy an existing one or create a new one.

 

Not knowing how the database handles all those archived PQ's, I would suspect that this isn't exactly a benefit to the database that generates the queries.

 

It is a well documented fact that a previously ran PQ gets a much lower priority than a newly submitted one; even if the new one is a copy of the one that won't run. Doesn't make a lot of sense from an automation perspective but GS had valid reasons for that algorithm at the time.

 

Any PQ that has been previously submitted will run as late or later in the day than it did the previous time it ran.

 

I have resorted to copying my PQ's and submitting the new ones. Takes a bit of repetitive keystrokes but it is the only way to guarantee reasonable turnaround on a PQ.

 

If you submit a brand new PQ and it doesn't show up in a few minutes (less than 10) then there is probably a problem with the PQ generator or your email account.

 

As has been noted in one of the many threads on this topic, by OpinioNate, the PQ philosophy/system/algorithm/method is under review and a vastly improved delivery mechanism is the intent. There is no published ETA, to the best of my knowledge.

 

Hope this clarifies.

Edited by Tequila
Link to comment

I spent about an hour yesterday, rebuilding (actually copying and renaming) all of my PQ's. I did this for two reasons.

 

First, I used to be able to get all the caches within 140 km of my home with 9 PQ's using the Date Placed option. In the last 12 days, there have been 210 new caches in that area. So I had to add a 10th PQ to continue to cover the same 140 km.

 

Second, my existing PQ's were arriving later and later in the day due to the scheduling algorithm. Usually about every 3 months I re-do them to move them back up in the queue. This ensures they are waiting for me when I get up.

 

This morning they arrived about 20 minutes after midnight PST time. One didn't arrived until 40 minutes after midnight.

 

This, I think, demonstrates, how significant the PQ volume is. If I understand things correctly, my PQ's should have been as close to the top of the queue as I could get them. And it still took 20 minutes for them to run. So there must have been a significant volume waiting to run exactly at midnight.

 

BTW, this post is an observation, not a complaint. I know the PQ system is being worked on and I have developed my own usage process that addresses my needs until such time as the new process is implemented.

Link to comment

For the last week or so, I've been noticing a "creep" in the time my weekly PQs run.

 

They have been running EARLIER. I think this means TPTB have made some changes that have stabilized the situation, at least for now.

 

And when they get the "everything runs in 2 hours" change in place, everything is golden.

Link to comment

I must be doing something wrong with my query. I am trying to run a query listing all of my finds. My profile says I have 251 finds, however the query only shows 234, and when I run the GSAK macro I get 234, and when I sort my caches by log type I get 249.

When I log milestones which number is it? The numbers make no sense?

Please help

Thanks!

Link to comment

I must be doing something wrong with my query. I am trying to run a query listing all of my finds. My profile says I have 251 finds, however the query only shows 234, and when I run the GSAK macro I get 234, and when I sort my caches by log type I get 249.

When I log milestones which number is it? The numbers make no sense?

Please help

Thanks!

When I look at your profile, it shows 251 finds, when I flip through them I count that 16 are archived, that leaves 235 active caches that you found, since this is only off by 1, I probably miscounted.

 

Based on that, it looks like your running a normal PQ and checking the "that I've found" box. Running a normal PQ like that will never return archived caches.

 

If you want to run a PQ thats guaranteed to contain all your finds, you have to run the special PQ at the bottom of the page, just click the button that says "add to queue" and you should get a PQ that includes all of your finds, regardless of archive or published status.

Link to comment

I ran a "my Finds" query today and it gave me the same results from my last query in February of 218 finds. After the few we found yesterday we should have a total of 228. I have never had a problem with them coming up before. Does anyone have any answers?

Thank you,

:P

Edited by werjustok
Link to comment

I ran a "my Finds" query today and it gave me the same results from my last query in February of 218 finds. After the few we found yesterday we should have a total of 228. I have never had a problem with them coming up before. Does anyone have any answers?

Thank you,

:)

1. Did you run your "My Finds" query immediately after logging your latest finds? If so, those new logs may not have made it into the query. Just like not swimming for an hour after eating, I recommend waiting an hour after your logging session before you order a "My Finds" query.

 

2. Another common source of confusion is opening an older "My Finds" GPX file that you saved on your computer. Check to make sure that your file ("123456.gpx" or "123456.zip") is dated the date you last received it. Your system may have renamed the latest file to avoid a filename conflict, like "123456[1].gpx" or "123456[1].zip."

Link to comment

As far as I can tell, Tuesdays are evil. My PQs generally run anytime between midnight and 2:30 Pacific, but last Tuesday, they only ran at 3PM Pacific, and it's now past 3PM Pacific and they still haven't run. :blink:

 

Edit: They're just now starting to come through at 5PM Pacific. Bit ridiculous if you ask me.

Edited by Search4Lancer
Link to comment

Switched to gmail (msn just doesn't want to play). Haven't had time to cache so I have not run extra PQs as of late. Did make note today to keep an eye out due to the reports of delivery problems and I see where I have two that ran almost an hour ago and are not delivered as of yet. Getting other mail and notifications.

 

edit to correct time zone mishap

Edited by SgtSue
Link to comment

I created two PQs: a standard one and then a route one a few minutes later

 

The route one shows as being generated (still no email though) the other one showed as 'never' despite being scheduled for today. So I deleted that one and created a new one but still nothing.... :laughing:

Link to comment

I created two PQs: a standard one and then a route one a few minutes later

 

The route one shows as being generated (still no email though) the other one showed as 'never' despite being scheduled for today. So I deleted that one and created a new one but still nothing.... :huh:

Same for me today.

 

New PQ from Bookmark (indicates ran, never delivered),

New PQ from Route (never ran), and

Activated from saved list (not ran).

 

Luckily, I'm trying to prepare for next weekend and can do it slowly...however... :laughing:

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...