Jump to content

Pq's Hit And Miss?


pppingme

Recommended Posts

I echo that FireRef...that is, not to consider this fraud. I am SO VERY HAPPY to have a way to get ANY cache information without having to do it by hand...

 

Is each PQ is generated by order of number? I have some that are 4xxxxx numbers and when I request them they will show up, but after all the 3xxxxx numbers that were requested have run. If that is the case, how come the newer ones are generated right away? And how come some that have run at 6am for me before are suddenly coming as late as 10pm?

I too, am a cat, and will probably die of curiosity some day...

Link to comment

Once weekly queries - working fine.

3 times a week - last due 2 days ago, no sign of it yet.

Daily - not working at all, last copied and ran on the 22nd

 

Would suspending the creation of new queries until all the older queries have been cleared out of the system be a sensible option?

Link to comment

Is each PQ is generated by order of number?

 

No. They are prioritized based on how often they run. The less often they run the farther up in the queue they are for the day they run. So if you run the same pocket query every day it'll be at the end of the line and you'll get it later and later in the day. So it pays to have pocket queries that you only run on demand or once a week.

 

The reason for this is obvious when you think about it - The more often it runs the more current the last pocket query is that you received. And folks being nice to the Pocket Query Generator and only running it when they need it get rewarded with a quick response time.

 

And of course new queries go to the front of the queue because when people run them for the day they want them immediately.

Link to comment

Is it true that if you are a premium member and get a pocket query, only the last four logs are included?

 

If yes, this might be why people run queries multiple times per week instead of just once or every other week. If the last 8 or 10 logs were included, then those that use pocket queries to keep offline databases like GSAK up to date would not be worried about missing logs.

Link to comment

So it pays to have pocket queries that you only run on demand or once a week.

 

I think that in all the years I've been running weekly PQs the system has only hiccuped once and missed them. :)

Edited by PDOP's
Link to comment

My 2 times weekly PQ's I run on Mondays and Fridays ran at 5:40 and 6:20 PM for both. They ran on time this week so I guess things are getting caught up now. :laughing:

I don't see why anyone would run the same PQ everyday. The only reason I would see why is if you can cache everyday but other than that I don't understand it. I think they ought to be punished too, I mean put in the back of the line :laughing:

Link to comment

Is it true that if you are a premium member and get a pocket query, only the last four logs are included?

 

If yes, this might be why people run queries multiple times per week instead of just once or every other week. If the last 8 or 10 logs were included, then those that use pocket queries to keep offline databases like GSAK up to date would not be worried about missing logs.

 

I think what was asked here is do PQ's only contain the last 4 logs. I checked mine and they seem to contain 5 logs max. If you get PQ's to update GSAK, you would want to run them at least twice a week to try and avoid missing logs for caches that might be found many times in a week. If more logs were included in a PQ, perhaps some folks would run them less frequently?

 

Running a PQ every day is hard to understand though.??

Link to comment

Running a PQ every day is hard to understand though.??

Not for me it's not! I only have 2 PQs and I'm allowed to run 5 a day so I can't see what the problem of running these two is :P

 

FWIW I run them to catch all the caches in Ireland (approx 600) so that I get a head's up on new cache placements and logs.

 

I keep a fully up-to-date offline db in my PPC and as I travel a lot through work I get a chance to pick up caches in many different places.

 

The daily PQs allow me to keep the database as close to live as possible to keep me informed of problems with existing caches or as already said to pick up new caches and possible FTF opportunities.

Link to comment

FWIW I run them to catch all the caches in Ireland (approx 600) so that I get a head's up on new cache placements and logs.

 

First, imagine what it's like in Chicago area - just in one portion of one state - where there's over 2,250 caches. Then imagine the southern California area where there's a bazillion caches within 100 miles of every point. :P

 

New cache placements: use insta-notify

Logs: Bookmarks and watchlists - and even then, why do you need copies of all of the logs, when they're available on Geocaching.com?

 

I keep a fully up-to-date offline db in my PPC and as I travel a lot through work I get a chance to pick up caches in many different places. The daily PQs allow me to keep the database as close to live as possible to keep me informed of problems with existing caches or as already said to pick up new caches and possible FTF opportunities.

 

I too have an offline database. But the best thing that ever happened to me was the realization that I didn't NEED to have my information up-to-the-minute accurate. Up-to-the-week is good enough, and I would think it should be in most instances.

 

What would be the absolute worst thing that would happen if you didn't know about a new cache, or didn't know that a cache that you thought was there was archived?

 

As to FTF opportunities, around here, if you don't have the Insta-Notify in place, GeoRon or GeoGil will find it first - way before anyone else would.

Edited by Markwell
Link to comment

I spend a lot of my cache perusing time off line in GSAK. So I actually do run a few of my local queries twice a week to keep the logs in GSAK as complete as possible. Even at that, I do miss a log here and there if a cache is found several times in a day or two. If I ran those PQ's 3X per week, I would probably not miss any logs, but I am happy with how it works at 2X. Or if more than 5 logs came in a PQ, then I could run the PQ's less often. Having the option to include more than 5 logs in a PQ would be nice when traveling since often those caches only get run one time.

 

I like having all the logs in GSAK so when I look at a cache page offline on my laptop or PDA, which is anytime I am not at home and connected, I can read them. Heck, I have even resorted to analyzing old log entries in the woods on my PDA to glean help to find a problematic cache.

 

I do use notification to get locally new caches.

Edited by Cheminer Will
Link to comment

Is each PQ is generated by order of number?

 

No. They are prioritized based on how often they run. The less often they run the farther up in the queue they are for the day they run. So if you run the same pocket query every day it'll be at the end of the line and you'll get it later and later in the day. So it pays to have pocket queries that you only run on demand or once a week.

 

The reason for this is obvious when you think about it - The more often it runs the more current the last pocket query is that you received. And folks being nice to the Pocket Query Generator and only running it when they need it get rewarded with a quick response time.

 

And of course new queries go to the front of the queue because when people run them for the day they want them immediately.

 

I understand running in an order of priority, but they should still run on the selected day, right? The pq with the least priority should still run? No biggie here - not in that big of a hurry, but missed pqs aren't a function of low priority, right?

Link to comment

Now been 7 days since my daily query has run, so have given up with that one.

Now created a new one which I shall select just before I want it to run.

 

But..... If I still manually run this everyday, will it still get shoved to the back of the queue (and most likely not run)? We shall see [:wub:]

Link to comment

I can't get the My Finds PQ to run. I get my weekly regularly scheduled ones and all the notifications. I put in a ticket and that didn't help. It gets queued but never runs. i have tried it 5 times in rthe last week. Put in another ticket tonight to see if that will help.

Link to comment

I can't get the My Finds PQ to run. I get my weekly regularly scheduled ones and all the notifications. I put in a ticket and that didn't help. It gets queued but never runs. i have tried it 5 times in rthe last week. Put in another ticket tonight to see if that will help.

 

I had a PQ in the queu for much of the day today that hadn't run. It had previously run a couple of days ago. Instead of waiting any longer for it, I instead reworked an older PQ that I hadn't run for months, which did the trick. It ran and the results showed up in my email in just a few minutes. Just had to work the system a little to get what I needed.

Link to comment

No. They are prioritized based on how often they run. The less often they run the farther up in the queue they are for the day they run. So if you run the same pocket query every day it'll be at the end of the line and you'll get it later and later in the day. So it pays to have pocket queries that you only run on demand or once a week.

 

The reason for this is obvious when you think about it - The more often it runs the more current the last pocket query is that you received. And folks being nice to the Pocket Query Generator and only running it when they need it get rewarded with a quick response time.

 

And of course new queries go to the front of the queue because when people run them for the day they want them immediately.

 

I only ever run my PQs on demand, I have never had permanently scheduled. When I'm looking for caches to do for the day, I tend to bookmark the 5-10 I want to go find on a "Today's Caching" bookmark list, then I go run a PQ for that bookmark list.

 

It used to take between 5-10 minutes for the PQ to run, now it takes more like an hour.

 

From Jeremy's explanation it looks like I should be creating a new bookmark list each day, a new pocket query for that bookmark list each day, then running it once, and after coming back in from caching, just going ahead and deleting both the PQ and bookmark list after logging. Then repeat the same process every day I go out caching so that my PQs will still run in 5-10 minutes since they're "new".

 

This just seems backwards, since I bet the overhead to make a new bookmark list, make a new PQ for the bookmark list, and then delete both the PQ and bookmark list is probably equivalent to the overhead from the PQ running anyway!

Link to comment

I created two new cache along a route Pq's. and neither have run.

 

Trying to figure out what is going on. I ran a regular pq that i run on demand (usually about once a week) and it took about 10 min to receive the data.

 

Any ideas as to why this is?

 

The route pocket queries were stuck. I started them back up.

Link to comment

Boy, I thought I understood this, but maybe not. Can someone explain? I have a few PQ's that run 2 times per week. Recently I noticed some did not run when scheduled. Today, (Friday), I had 3 scheduled and only one ran.

 

I saw someone say something like PQ'a that are run a couple of times per week, every week, lose priority and get later and later in the day each week until they don't run before midnight of the scheduled day and are missed. Is this true? Sounds crazy to me, but may be why mine did not run today?

 

If the above is not accurate, then why aren't the PQ's running when scheduled?

Link to comment

I requested two PQs Friday night. They had previously run on Thursday, so I knew I shouldn't expect them quickly...but they never ran.

 

Does this mean we have again reached the point that not all queries will run on certain days? If so, is there any way that information can be communicated to us?

Link to comment

As I have stated before, I don't have any scheduled PQs. I run one for whatever direction I am heading the day before I am going on a caching adventure. The PQ usually runs within 10 minutes. :laughing:

 

I have many PQs in my list. All of them are for 500 caches with a 100-mile radius (this is a very cache-rich area). I know the circles overlap a lot, but that is okay because I don't run all of them -- only the one, or two, I need.

 

Maybe what you could do is set up at least seven new PQs and, if you need them to be scheduled, run one of them Monday, a different one Tuesday, another one Wednesday, etc. If the circles are large enough, you should get all the data you need . . . unless you want every single log on every single cache in your area.

 

If you do that, the Monday one will be higher in the queue the following Monday since it has been seven days since it ran.

 

I exclude the Puzzle caches from my regular PQs. I run that one once in a while and put those in a separate GSAK Puzzle database so I don't have to see those 8.gif in my Default databse and have them remind me how much I suck at Puzzles . . . :laughing:

Link to comment

...I saw someone say something like PQ'a that are run a couple of times per week, every week, lose priority and get later and later in the day each week until they don't run before midnight of the scheduled day and are missed. Is this true? Sounds crazy to me, but may be why mine did not run today?...

I've been testing this theory for a week. I have one query that runs every day. Each day I've been getting them later and later. Of course, eventually, I did not get them. When I copied the pocket query this morning and set it to run, I received an email containing the pocket query within 3 minutes.

 

Their website states that it's better to schedule the pocket query in advanced rather than scheduling it on the day you want it. Based on my experience above, this appears to be false. If I set a query to run on the day I want it, I usually get it within an hour or two. If I set it in advance, I get it late that evening.

 

People do pay for this service. *If* they are going to be prioritizing queries, they should state that on their webpage. If paying an extra 10 dollars a year would increase their pocket query server or bandwidth to allow the pocket queries that people want, then I wouldn't mind paying it.

Link to comment

Yes, this is what seems to be happening to my PQ's. Later and later until they just get skipped. However, I guess after getting skipped once, they should move back higher in the Que and run the next time???

 

I don't think Groundspeak does it to us on purpose. I think it must be a quirk or bug that just needs to get fixed because as a premium member, I am fairly certain they would not want to prevent you from scheduling a certain PQ to run a couple of times a week. You are right that this is an expected premium member feature, I think.

 

I have several PQ's that each run twice a week. Using this with GSAK allows me to keep my local database up to date. I don't think I am abusing the premium membership benefits by scheduling several PQ's to run twice a week, am I? I still almost never reach my 5 per day allotment.

Edited by Cheminer Will
Link to comment

Another followup on my experiments.

Created a new query (set to run once) Thursday night, arrived within 15 minutes.

Selected the query to run again this morning (Saturday, 14 hours ago), no sign of it yet.

(EDIT: Arrived after 22 hours)

 

I can understand Jeremy and the team are probably frantically doing maintainance behind the scenes to try and fix things, but I'm sure an official announcement in the announcements forum would be appreciated by everyone.

Edited by Jaz666
Link to comment

First of all apologies for the late reply. I have been away for a while and missed the reply

FWIW I run them to catch all the caches in Ireland (approx 600) so that I get a head's up on new cache placements and logs.

 

First, imagine what it's like in Chicago area - just in one portion of one state - where there's over 2,250 caches. Then imagine the southern California area where there's a bazillion caches within 100 miles of every point. :laughing:

 

New cache placements: use insta-notify

Logs: Bookmarks and watchlists - and even then, why do you need copies of all of the logs, when they're available on Geocaching.com?

I take your point but I can't see what this has to do with what I'm talking about :rolleyes:

 

I keep a fully up-to-date offline db in my PPC and as I travel a lot through work I get a chance to pick up caches in many different places. The daily PQs allow me to keep the database as close to live as possible to keep me informed of problems with existing caches or as already said to pick up new caches and possible FTF opportunities.

 

I too have an offline database. But the best thing that ever happened to me was the realization that I didn't NEED to have my information up-to-the-minute accurate. Up-to-the-week is good enough, and I would think it should be in most instances.

Not really. If it's a busy cache with more than 5 visits in a week then you lose some of the logs. The missing log(s) may be the difference between finding the cache and not.

 

What would be the absolute worst thing that would happen if you didn't know about a new cache, or didn't know that a cache that you thought was there was archived?

 

As to FTF opportunities, around here, if you don't have the Insta-Notify in place, GeoRon or GeoGil will find it first - way before anyone else would.

Irrelevant to me as I live in a different country so I don't know why you're making this point.

 

It suits me to run the 2 daily PQs, it suits me to have a fully up-to-date database so that I can work offline as much as possible (travel a lot and don't have broadband at home) and it always worked before. Then it stopped, re-started, hiccupped and has stopped again.

 

The most annoying thing is that there appears to be no explanation of what is being done to prevent these problems from occurring apart from a nonsensical (IMO) workaround.

Link to comment

I can confirm the testing of the others-- I have a single pq that is scheduled to run several times a week. It runs later and later each day until it eventually gets skipped.

 

When I modified the pq to "uncheck after it runs" it still does not show up for quite a while (hours), but if I copy to a new pq, the new one shows up right away. As I expect it should since priority goes to new queries.

 

I suspect that those who run their queries "on demand" use this "copy" routine, as this is the only way I can find to generate a pq and get it immediately. The Groundspeak recommendation that you only run a pq when you need it would encourage this.

 

If that's the case, and the Groundspeak perferred method, then why not have a "download" function for existing pq's (for gpx files not just loc's)? If nothing else that should relieve some burden of transfering the file to an email server.

 

If this is not the Groundspeak preferred method, than I agree with the other posters that it makes more sense to give priority to the scheduled pq's than the new ones.

 

An added membership cost of "on demand" pq's would be acceptable to me as well.

 

If nothing else, the pq restrictions to be set to the limits of what the system can bear.

Link to comment

If that's the case, and the Groundspeak perferred method, then why not have a "download" function for existing pq's (for gpx files not just loc's)? If nothing else that should relieve some burden of transfering the file to an email server.

 

That could be a very interesting option (I say option, as we should be allowed to choose whether we prefer EMails or manual downloads).

 

I could see it working with a credits system, in keeping with the current system, allowing a maximum of 40 downloads in a 7 day period.

 

I've concluded that you can just about get away with running the same query twice in a row, but then you have to leave it at least 3 days before trying again.

Not having an up-to-date local database has caught me out a few times in the field recently.

Link to comment

If that's the case, and the Groundspeak perferred method, then why not have a "download" function for existing pq's (for gpx files not just loc's)? If nothing else that should relieve some burden of transfering the file to an email server.

 

That could be a very interesting option (I say option, as we should be allowed to choose whether we prefer EMails or manual downloads).

Maybe I missed something, but I think we already have this option. If you check 'run once and uncheck' (or whatever it is), the PQ remains but will not run again until checked again.

 

On another matter not related to the above quotes, If everyone(or alot) is running unecessary tests to see how long it takes a PQ to get into there mailbox, isn't this just adding to the burden to the server?

I went through my PQ's and unchecked the ones I really don't use everyday/week to aleviate some pressure off the server. Think if 50% of the premium members did this to just 1 PQ that this problem would get better until Groundspeak resolves the problem? As I stated before, the new feature 'caches along a route' is adding a lot of PQ's to the Groundspeak servers and this will slowly calm down as the 'newness' wears off.

Just my 2 cents...

Shilo

Link to comment

I only have one PQ that I used to run 7 times a week. I reduced it to 3 times a week. Seems to have gotten worse. My Friday one didn't run until Saturday afternoon. :laughing:

Its going to take more than you and me doing this. It's definately not the scenario we and Groundspeak want but servers cost money and I don't have the money to donate to get them a bigger one. Hopefully the abundance of PQ's being run here lately will settle down. But then again it is summertime and more people are out geocaching now than will be in february.

Link to comment

I suspect that those who run their queries "on demand" use this "copy" routine, as this is the only way I can find to generate a pq and get it immediately. The Groundspeak recommendation that you only run a pq when you need it would encourage this.

 

Everybody keeps talking about "copying" theior pq's. Are you just talking about re-writing them again, or is there a copy routine I don't know about?

Link to comment

Everybody keeps talking about "copying" theior pq's. Are you just talking about re-writing them again, or is there a copy routine I don't know about?

There is a "routine". If you go to your pq page, one of the icons is a "copy". If you click that, and you have at least 1 of the 40 slots available, it will copy that pq and add something like "Copy of ..." to the beginning of the name. Saves a lot of work. :laughing:
Link to comment

Is anyone else having a problem getting the emails when the pq finally does run?

What I mean is, the pq list shows the query ran, but sometimes the email never arrives. I also occasionally do not receive log entries for my caches and forum reply notifications.

 

I don't believe it to be a "filter" issue as I'm not using any blacklists and I get notification from the server of anything rejected on my end.

Link to comment

Is anyone else having a problem getting the emails when the pq finally does run?

What I mean is, the pq list shows the query ran, but sometimes the email never arrives. I also occasionally do not receive log entries for my caches and forum reply notifications.

 

I don't believe it to be a "filter" issue as I'm not using any blacklists and I get notification from the server of anything rejected on my end.

 

Yup! :laughing:

Haven't received 2 I've created.

Link to comment
Is anyone else having a problem getting the emails when the pq finally does run?

The only time I had a problem like this is when I inadvertently filled up my web space, which is shared with my email space :grin: Now that I know, I make sure to leave several MBs of room.

Link to comment
Simple question, when will it be fixed? Day 5 of not receiving a query, and then only when I redid it. It's broke, prioritization or not, it's not about patience, it's simply broke.

I doubt this will be addressed anytime soon, as TPTB do not see a problem. It is working as they want it to.

 

Please remember that earlier in this thread the TPTB indicated that those us that percieve a problem are just too impatient to wait.

 

TPTB have already blessed the work around for their ill conceived PQ prioritzation scheme and they see nothing wrong with it. Their game, their rules accept it and do not question it.

 

The work around for those us that are too impatient to wait is to create a new copy of the query we are trying to get run. Schedule it for today in a few minutes you should get the PQ in your email. Don't forget to delete the copy PQ so it doesn't take away from the 40 total PQ's you can create but not run on any sort of reliable reocurring schedule.

 

As time goes on this work-around will cease to function as well. There will be far too many PQ's for the PQ machine to handle.

 

Until this gets fixed maybe they should disable the ability to schedule reoccuring PQ's.

Link to comment
Dumb Question - I guess this would be for Jeremy. How many PQ's run every day? How long does it take for the average PQ to run? I guess I'm just confused as to how long it can take that some of these normally can run immediately (because of the newness of the query) and some can take half a day. This is just a curiousity thing. I don't consider it in any way to be fraud for a service to have occasional glitches - especially at $3 a month.

It's not that they take half a day to run. They are all prioritized by when they ran last. Therefore, a PQ that is requested to run daily is behind many others PQ requests. These PQs run one after the other all day long. If they all run before midnight, everybody's happy. If they do not all run by midnight, the ones that haven't run, won't run because the PQs for the next day start running.

Link to comment
People playing with this isn't helping the PQ situation. Probably the cause of PQ's that are set to run every week/day from being run at all or later and later since new PQ's are run first.
I don't think so.

 

While it's true that people fooling around with 'Caches on a route' might be causing a few more PQs, I think the route functionality will serve to greatly reduce the number of PQs run.

 

A few weeks ago, I made a road trip from Hartford, CT to Binghamton, NY to Cattaraugus, NY to Niagara Falls, NY to Binghamton, NY to Stamford, CT to Hartford, CT. If I used the old way to run PQs to get caches near this route, it would have taken probably a dozen PQs (or more). With the new procedure, I only ran one. (I got it in just a few minutes. Thanks, Jeremy!)

Edited by sbell111
Link to comment
It's not that they take half a day to run. They are all prioritized by when they ran last. Therefore, a PQ that is requested to run daily is behind many others PQ requests. These PQs run one after the other all day long. If they all run before midnight, everybody's happy. If they do not all run by midnight, the ones that haven't run, won't run because the PQs for the next day start running.
Really? I have one that runs Monday, Wednesday, and Friday. I did not receive it on Friday. However, I did receive it on Saturday afternoon.
Link to comment
It's not that they take half a day to run. They are all prioritized by when they ran last. Therefore, a PQ that is requested to run daily is behind many others PQ requests. These PQs run one after the other all day long. If they all run before midnight, everybody's happy. If they do not all run by midnight, the ones that haven't run, won't run because the PQs for the next day start running.
Really? I have one that runs Monday, Wednesday, and Friday. I did not receive it on Friday. However, I did receive it on Saturday afternoon.

That sounds more like an email issue than a PQ generation issue. When did it run according to the PQ page?

Link to comment
It's not that they take half a day to run. They are all prioritized by when they ran last. Therefore, a PQ that is requested to run daily is behind many others PQ requests. These PQs run one after the other all day long. If they all run before midnight, everybody's happy. If they do not all run by midnight, the ones that haven't run, won't run because the PQs for the next day start running.
Really? I have one that runs Monday, Wednesday, and Friday. I did not receive it on Friday. However, I did receive it on Saturday afternoon.

That sounds more like an email issue than a PQ generation issue. When did it run according to the PQ page?

1:15pm PST on Saturday (local time 4:15 on Saturday afternoon). Doesn't sound like an email issue.
Link to comment
It's not that they take half a day to run. They are all prioritized by when they ran last. Therefore, a PQ that is requested to run daily is behind many others PQ requests. These PQs run one after the other all day long. If they all run before midnight, everybody's happy. If they do not all run by midnight, the ones that haven't run, won't run because the PQs for the next day start running.
Really? I have one that runs Monday, Wednesday, and Friday. I did not receive it on Friday. However, I did receive it on Saturday afternoon.

That sounds more like an email issue than a PQ generation issue. When did it run according to the PQ page?

1:15pm PST on Saturday (local time 4:15 on Saturday afternoon). Doesn't sound like an email issue.

Email servers only hiccup at certain times of the day? :laughing:

Link to comment
It's not that they take half a day to run. They are all prioritized by when they ran last. Therefore, a PQ that is requested to run daily is behind many others PQ requests. These PQs run one after the other all day long. If they all run before midnight, everybody's happy. If they do not all run by midnight, the ones that haven't run, won't run because the PQs for the next day start running.
Really? I have one that runs Monday, Wednesday, and Friday. I did not receive it on Friday. However, I did receive it on Saturday afternoon.

That sounds more like an email issue than a PQ generation issue. When did it run according to the PQ page?

1:15pm PST on Saturday (local time 4:15 on Saturday afternoon). Doesn't sound like an email issue.

Email servers only hiccup at certain times of the day? :mad:

Huh? What I'm saying is that from the looks of things, I probably got my email within a very short period after the PQ was generated. The PQ time shows that the "Friday" one was logged on Saturday afternoon. Are you saying that the logged time was when it was actually emailed, rather than when it was actually run?

 

Me begins to thinks the Emperor is missing some clothes. :laughing:

Link to comment
Email servers only hiccup at certain times of the day? :mad:

Huh? What I'm saying is that from the looks of things, I probably got my email within a very short period after the PQ was generated. The PQ time shows that the "Friday" one was logged on Saturday afternoon. Are you saying that the logged time was when it was actually emailed, rather than when it was actually run?

 

Me begins to thinks the Emperor is missing some clothes. :laughing:

I thought that it was the time the PQ was generated. I would need more information to determine whether your specific situation fits into the subject of this thread.

Link to comment

 

Until this gets fixed maybe they should disable the ability to schedule reoccuring PQ's.

A liitle over a year ago it was like this. I didn't know it and was wondering where my PQ's went.

A note to this effect was in the e-mail with the PQ which I didn't read and most others didn't either.

I didn't much care for it because I wanted my PQ every friday morning.

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