Jump to content

Release Notes 4/29/10

OpinioNate

By OpinioNate
in Website

Followers 12

Recommended Posts

Chrysalides

+Chrysalides

Posted
Posted

I used to be a programmer. (I could even write in Assembly.) I have a theory about the "cache in the middle of nowhere" problem. If, as everyone seems to indicate, it is a very old one, then my guess is that someone put a line or two of code into the soup to test things and forgot to take it out. I've done it and I've seen other good programmers do it. It was basically put there to prove that a particular subroutine is being executed. But, this is just a guess.

 

BTW: let me again beg that .loc files be kept as an option.

It certainly sounds plausible. I'm still getting the random old cache in the map view with 2 of my 5 regular PQs. The other 3 might have them, but it's not far off hence not visible.

 

Doesn't explain why I'm coming up about 240 caches short in the map view compared to downloaded PQ though (~700 instead of 995).

W8TTS

+W8TTS

Posted
Posted

I just noticed that when I save a PQ all the spaces from the name are removed. Is this intended or a bug?

It appears to be a bug.

Canadavey

+Canadavey

Posted
Posted

Todays attempt on my part shows my PQ=720, the same results appear when downloaded to my GPS.

The map shows only 663 with a stray cache of GC8BD6 several hundred miles away.

 

I have the same issue. My stray cache is GC6 thousands of miles away. I also have the same problem as a lot of people with the map preview showing less caches then what's actually included in the PQ. I'm using IE8, up to date.

dfx

+dfx

Posted
Posted

I just noticed that when I save a PQ all the spaces from the name are removed. Is this intended or a bug?

probably half intended as a workaround to fix losing the .zip file extension. not the proper fix though :)

dfx

+dfx

Posted
Posted (edited)

I used to be a programmer. (I could even write in Assembly.) I have a theory about the "cache in the middle of nowhere" problem. If, as everyone seems to indicate, it is a very old one, then my guess is that someone put a line or two of code into the soup to test things and forgot to take it out. I've done it and I've seen other good programmers do it. It was basically put there to prove that a particular subroutine is being executed. But, this is just a guess.

plausible, but everyone seems to get different caches as their stray caches. seems to be more of an off-by-one error to me.

Edited by dfx
W8TTS

+W8TTS

Posted
Posted

I have the same issue. My stray cache is GC6 thousands of miles away. I also have the same problem as a lot of people with the map preview showing less caches then what's actually included in the PQ. I'm using IE8, up to date.

I just tried this on a current version of Firefox and the map takes me first to Seattle WA, a few thousand miles away. But, later as the caches are loaded it takes me back to my home coordinates. But, the Search Results show "722 Caches Displayed" when the PQ contains 993 caches, and there is the one lost cache (GC1A8C) a few hundred miles away in New York. And, GC1A8C doesn't appear to be in the PQ.

Avernar

+Avernar

Posted
Posted

I just noticed that when I save a PQ all the spaces from the name are removed. Is this intended or a bug?

A bug that's a fix for another problem. Slashes are also removed. Makes it harder to read the PQ titles.

 

The character filtering for the filename should really be done when generating the file and not when saving the PQ setting.

dfx

+dfx

Posted
Posted (edited)
The character filtering for the filename should really be done when generating the file and not when saving the PQ setting.

it's not even necessary to do that, it's perfectly possible to offer files with spaces or dashes in their names for download.

 

PS: to elaborate on that: the Content-Disposition header is defined in rfc 2183, which defines the filename parameter as filename-parm := "filename" "=" value while saying that "value" is defined in rfc 2045, which in turn defines it as value := token / quoted-string, with "quoted-string" of course being defined in rfc 822 (gotta love those rfcs). long story short, just put quotes around the filename, escape quotes inside the filename and backslashes with a backslash, and it's gonna work fine. (of course it may be wise to still filter out quotes, backslashes, slashes and other "problematic" characters such as colons from the filename, even though not strictly necessary.)

 

Content-Disposition: attachment; filename="4266561_home by age08.zip"

 

works just fine.

 

all that being said, i never liked using that header in my own stuff as it breaks downloads on browsers not supporting it (such as IE mobile). a better option is to use the equivalent of path-info, for example using download links like this:

 

http://www.geocaching.com/pocket/downloadp...0by%20age08.zip

 

which would work uniformly across all platforms and would obsolete that pesky header.

Edited by dfx
Hynr

+Hynr

Posted
Posted (edited)

With the new functionality, the text of the "Your Pocket Query" page required modification. I would like to recommend some improved language for the text on this page. Currently it reads:

Queries that contain 500 geocaches or fewer can be delivered as an email attachment. You can run up to 5 pocket queries every 24 hour period, but each individual search can run only once per day.
Since queries do not contain caches (those are in the "output" from executing a query, and technically it is not the caches you find there, but the cache data) I would suggest replacing the first of these two sentences with: "The resulting data will be made available for downloading here; queries that request 500 geocaches or fewer will also be delivered as an email attachment to the email address specified in the query."

 

With regard to the second sentence, it is not true. You can run as many as 10 in a 24 hour period. Here is how: Let's say the current time is a few hours before midnight PST and you have 10 PQs that you need to have run in the next big batch the the PQ processors runs (starting at midnight PST) and you have run no PQs since the last midnight in Seattle. Then you can get 5 of those to run before it is midnight in Seattle, and you can schedule 5 more to run within a few hours thereafter. The total time between the first of the 10 and the last of the 10 to run can be less than a few hours. So to correct the language of the second sentence, the following text would perhaps be better: "You can run up to 5 pocket queries during any day (midnight to midnight Pacific Standard Time), but each individual search can run only once per day".

 

With the amount of critical thinking that prevails in this forum, someone can probably suggest even better text.

Edited by Hynr
Semper Questio

+Semper Questio

Posted
Posted

I don' tknow if this is a result of the recent changes since I don't really know when this started or if it is only happening to, but here goes...

 

I just noticed that if I try to view my Ignore List I get a screen that says....

 

Geocaching > Bookmark Lists > View Bookmark List

View Bookmark List

 

You do not have permissions to view this list.

 

I verified that I am signed on. I even signed out, cleared cache and cookies, and signed back in with the same result. This is if I select Ignore List from the book mark list on a cache page or from my Bookmarks list.

 

I can still click on the Ignore Cache link to ignore or restore a cache and that works fine. I just can't look at the bookmark list.

 

I am using FF 3.6.3 on Windows XP Pro SP 3

 

Anyone else?

Cache O'Plenty

+Cache O'Plenty

Posted
Posted (edited)

With the new functionality, the text of the "Your Pocket Query" page required modification. I would like to recommend some improved language for the text on this page. Currently it reads:

Queries that contain 500 geocaches or fewer can be delivered as an email attachment. You can run up to 5 pocket queries every 24 hour period, but each individual search can run only once per day.
Since queries do not contain caches (those are in the "output" from executing a query, and technically it is not the caches you find there, but the cache data) I would suggest replacing the first of these two sentences with: "The resulting data will be made available for downloading here; queries that request 500 geocaches or fewer will also be delivered as an email attachment to the email address specified in the query."

 

With regard to the second sentence, it is not true. You can run as many as 10 in a 24 hour period. Here is how: Let's say the current time is a few hours before midnight PST and you have 10 PQs that you need to have run in the next big batch the the PQ processors runs (starting at midnight PST) and you have run no PQs since the last midnight in Seattle. Then you can get 5 of those to run before it is midnight in Seattle, and you can schedule 5 more to run within a few hours thereafter. The total time between the first of the 10 and the last of the 10 to run can be less than a few hours. So to correct the language of the second sentence, the following text would perhaps be better: "You can run up to 5 pocket queries during any day (midnight to midnight Pacific Standard Time), but each individual search can run only once per day".

 

With the amount of critical thinking that prevails in this forum, someone can probably suggest even better text.

Slight correction to "... queries that request 500 geocaches or fewer will also be delivered...". "Request" is actually "results in". Technically you are correct that queries requesting <=500 caches will always result in <= 500 and thus will be emailed.

Edited by Cache O'Plenty
tozainamboku

+tozainamboku

Posted
Posted

I noticed that to fix the problem some people were having downloading PQ file with odd characters in the name you now remove the characters. I never ask for the the name of the PQ to be appended to my PQ (I've set up another tool to help me keep track of which ID number goes with which PQ) so this shouldn't effect me, but when I changed the place by date in the PQ I also change the name and now the forward slashes are removed. So instead of "North before 11/22/2009" I now get Northbefore11222009. That's pretty ugly and hard to read.

 

I'm beginning to agree with Avenar and others that Groundspeak seems incapable of giving new features without breaking something we've been used for a long time.

 

I know its just aesthetics and I can live with the ugly name. But I also know that it means the designers are not doing a very good job of looking at the effects of a change. As I said, I don't use the name of the PQ in the file name so it really should have not had any effect on me.

LightHouseSeekers

+LightHouseSeekers

Posted
Posted

LHS: What browser are you using?

 

-Raine

IE 7, Version 7.0.5730.11.

Though that is probably no longer relevant as I see in a later posting the problem is now fixed.

I'll verify that today I did NOT see the stray cache issue.

BaerTracks

+BaerTracks

Posted
Posted

Removing the spaces from the pq name breaks my system using GSAK and macros that automatically download the pqs and load them into the correct database name in GSAK. This system works well and many are using it. If the database name in GSAK, for example, is Home then the pqs would be Home 1, Home 2, etc etc. This only works if there is a space between the Home (database name) and the numeral 1.

 

It's taken me a year and a half to perfect this system. Please allow spaces in pq names.

 

thx

FancoverFive

+FancoverFive

Posted
Posted

One of my PQs is displaying wrong. It should be "0 1 Nearby", but it's listed as "01Nearby". All of my other dozen pocket queries with spaces in the name are working fine.

BCNorwich

+BCNorwich

Posted
Posted

Seems like when you create a new PQ or edit an existing PQ then all spaces are removed, very irritatating. The new 1000 cache PQ also have the spaces removed. Existing PQ if left unedited seem to stay with the spaces in the name.

 

Again please can this be reverted to allow spaces.

 

Regards

Bernard

dfx

+dfx

Posted
Posted

Seems like when you create a new PQ or edit an existing PQ then all spaces are removed, very irritatating. The new 1000 cache PQ also have the spaces removed. Existing PQ if left unedited seem to stay with the spaces in the name.

 

Again please can this be reverted to allow spaces.

i hope they do, post #265 contains everything they need to know to get this fixed.

Alan White

Alan White

Posted
Posted

Again please can this be reverted to allow spaces.

I agree. I had assumed that this removal of spaces was only from the downloaded filename but I see that spaces are removed from the actual name of the PQ. Surely Groundspeak can see how silly that looks and how hard it makes it to read the PQ name?

 

By all means (as far as I'm concerned) remove spaces from the filename but removing them from the PQ name makes no sense at all.

Lil Devil

+Lil Devil

Posted
Posted
By all means (as far as I'm concerned) remove spaces from the filename but removing them from the PQ name makes no sense at all.

There seems to be limited things they can hotfix without doing a full update. This was probably the easiest solution they could hotfix until next month when they can fix it properly in the full update.

dfx

+dfx

Posted
Posted
And slashes. I have them for dates. ex 2010/05/08

slashes in filenames are Evil™.

 

of course it's really the client's responsibility to strip out any invalid characters, but i can understand a web developer if they don't want to the trust the clients to do that.

Alan White

Alan White

Posted
Posted (edited)

Of course, all these problems with filenames are only problems if "Include Pocket Query name in download file name" is checked. If, as I do, you leave that unchecked then there's no reason at all for Groundspeak to be messing about with the PQ name, yet they do.

Edited by Alan White
Avernar

+Avernar

Posted
Posted

slashes in filenames are Evil™.

I didn't ask for slashes in filenames, just the PQ titles like we had before.

 

It's the job of the function that generates the filename from the title to strip out all non filename characters: slashes, colons, etc.

 

I don't have the checkbox to include the PQ name in the filename checked anyway.

dfx

+dfx

Posted
Posted
I didn't ask for slashes in filenames, just the PQ titles like we had before.

oh yes of course. any editing of the names of PQs makes no sense at all.

Holy Grail

+Holy Grail

Posted
Posted

"My Finds PQs are no longer sent as email attachments, but will be available as a file download"

 

I think, that is not acceptable. I automated my whole Email/Gsak stuff and now I´ve to go to the Groundspeak site, activate the "My Finds" (ok, this I had to do before, but this would also be a future feature, to have a check box, where you can say, please send my finds as attachment every 7 days automatically), than I have to wait for a email to arrive, saying that the "My Finds" are available, than go to the site again and download the stuff . My outlook is saving the attachments stuff automatically in a folder and Gsak is importing it. This so called "new feature" is a huge step back and I think many people are not pleased with this.

 

"after all, the PQ generator had already been under an extremely heavy load, and "now you want us to deliver more!?"

 

If you experience extremely heavy load because of PQ´s, than buy new hardware or program it better, "load balancing" can not be so difficult to handle the not so complicated PQ stuff or? :anicute:

 

Greetings

Holy Grail

Hynr

+Hynr

Posted
Posted

I thought there had been some work to address the fact that PQs were returning incorrect numbers of caches.

 

I had three PQs run this morning (scheduled, circular, using Placed date to limit number by 500). The results in the download folder are now a few hours old, but I am seeing this consistently.

 

When I click on the preview on the "Active Pocket Query" tab I get one number (the same with either of the two previews); in the table for downloads, I see a different number and that number corresponds to what is actually in the gpx file. The table below identifies these numbers; A, B, C are ones that ran today. I also have one (N) that ran during the week where the preview showed on the day of the run that it was maxed out, but the download does not reflect that.

PQ Preview Download
== ======= ========
A   481	   484
B   476	   479
C   484	   476
...
N   500	   488

I wonder if anyone is getting ready to schedule a PQ to run right away to test what the preview shows you and and what the result is immediately after that in the Download tab.

Keystone

Keystone

Posted
Posted (edited)

Hynr, those variations are quite possible within a single day of normal activity; i.e., caches being archived or disabled since the time when the GPX file was generated.

 

Also, do your pocket queries include caches that are on your ignore list? If so, then these caches will show up in the download file but will not be displayed in the preview.

Edited by Keystone
Chrysalides

+Chrysalides

Posted
Posted

I did a random check of 3 PQs. Two of them has tallies that agreed between PQ, map preview, and list preview. One of them has one less in the map preview, and that is because the cache is in my ignore list.

 

Why an ignored cache would show up in list preview and PQ but not in map preview is anyone's guess. I did not select "are not on my ignore list".

FancoverFive

+FancoverFive

Posted
Posted

I did a random check of 3 PQs. Two of them has tallies that agreed between PQ, map preview, and list preview. One of them has one less in the map preview, and that is because the cache is in my ignore list.

 

Why an ignored cache would show up in list preview and PQ but not in map preview is anyone's guess. I did not select "are not on my ignore list".

 

Because I assume the map refuses to show any caches that are on the ignore list, even if the PQ includes them.

dfx

+dfx

Posted
Posted
Because I assume the map refuses to show any caches that are on the ignore list, even if the PQ includes them.

obviously yes, because obviously the PQ preview uses a different code base than the PQ generator itself. which kinda kills the purpose of a preview, if it doesn't really show you what you're gonna get.

hulmgulm

+hulmgulm

Posted
Posted

Bug

 

When I enter a slash "/" in the PQ name, I always get

 

"Sorry, the requested Pocket Query download is no longer available."

 

when I try to download the PQ. So it's the same as it was with the spaces!

Cheminer Will

+Cheminer Will

Posted
Posted

I use dates like "5/30/2010" in my PQ's and I get them in email and they also work for downloading. I do notice that sometimes, but not always, the "/" are stripped from the name of the PQ in the list on the downloads tab. But they always work regardless.

Guest
This topic is now closed to further replies.
Followers 12
Go to topic listing
×
×
  • Create New...