Jump to content

Release Notes 4/29/10


OpinioNate

Recommended Posts

I change my schedual PQ's to get a result of 1000. I got the e-mail saying they are ready for download. I downloaded them and notice the icon was a bit different and isn't a zipfile anymore (It's a paper icon). So I went to put them into GSAK and get this error message:

Try this first : add a ".zip" extension to the filename and double click on it to open (or send it to GSAK).

 

If that does not work, try opening it in a hex editor and show us the first few lines of it.

Edited by Chrysalides
Link to comment

A couple of things... I'm sure they've been addressed already, but I'm asking anyway, LoL

 

the .zip extension will only show up for download when you do NOT click the add the query name to the file checkbox. Is this a bug?

 

I've previewed the PQ by listing and it shows the 1000 caches, however, when I view the PQ on the map, it shows only 655 caches... anyone else get something like this?

 

I'm loving the larger PQ size BTW :-)

Link to comment
I can't get the GPX file from the new downloading method to work in GSAK or dumping it directly in to my Oregon. :ph34r:

 

Tapeworm, I downloaded 3 PQ's this morning into GSAK by telling Firefox to open the file with GSAK and they worked fine.

 

Can you be more specific about what you did and what happened?

I change my schedual PQ's to get a result of 1000. I got the e-mail saying they are ready for download. I downloaded them and notice the icon was a bit different and isn't a zipfile anymore (It's a paper icon). So I went to put them into GSAK and get this error message:

 

5daf59e9-5762-4b54-b5df-42f34074d815.jpg I have the latest update from GSAK and the latest software/firmware update for the Oregon and dropping it directly into the Oregon doesn't work.

 

Thanks Tapeworm, what browser, operating system are you using?

to try to understand what is happening here.....

when I go to download in Firefox on Windows 7 it looks like this, so it's a zip and I tell GSAK to open it

125hpab.jpg

 

If you outline the exact steps maybe one of us can understand what is going wrong

Link to comment
I've previewed the PQ by listing and it shows the 1000 caches, however, when I view the PQ on the map, it shows only 655 caches... anyone else get something like this?

I don't know if someone mentioned this specific issue, but I tried with one of mine. 998 in PQ, 753 displayed, and one of them is an archived cache way outside the parameters of the PQ (the archived one appearing has been mentioned a few times). Thought that was a little amusing.

Link to comment

Thank you for all the great fixes so we can have FUN! Sorry to have to ask for more.... but... when will we see a http://m.geocaching site designed for viewing via a PDA/Cell-Phone screen? There's too much stuff on the main page to get to my field notes via a Blackberry screen. A mobile URL with just "options for action" would make the GeoCaching experience truly paperless AND 100% mobile. Thanks for considering it.

Link to comment

Thank you for all the great fixes so we can have FUN! Sorry to have to ask for more.... but... when will we see a http://m.geocaching site designed for viewing via a PDA/Cell-Phone screen? There's too much stuff on the main page to get to my field notes via a Blackberry screen. A mobile URL with just "options for action" would make the GeoCaching experience truly paperless AND 100% mobile. Thanks for considering it.

There is a http://wap.geocaching.com/ - are you referring to something like that?

Link to comment
It's not out of the question that we would work with GSAK or find some other way to serve PMs like yourself that prefer to automate your PQ consumption. This is a first step.

It would be fantastical to be able to have one way to access the PQs. I see you mentioned that emailed PQ would also have a stored counterpart. What if we could select to not have any PQs emailed to us and use only the stored PQ? Branching adds complexity to any system. If I am forced to branch, I might as well stay the way I am and not be part of any gain for the system.

 

This is not a bad idea. If I had the option to turn off email attachments entirely, I would gladly choose it and simply download my PQs when I needed them.

+ 1

 

Even on the road, as long as I have Wifi Access, I can download a Pocket Query from the Web site just as easily as (sometimes more easily than) I can deal with an e-mail attachment. I would definitely opt for a download-only scenario if that were available.

 

--Larry

I am probably missing something, but as I understand it this feature is built in. Make sure every one of your PQs request the cache number maximum to be 501 or greater, and the only thing you get by email is confirmation when each was processed.

Link to comment
Even on the road, as long as I have Wifi Access, I can download a Pocket Query from the Web site just as easily as (sometimes more easily than) I can deal with an e-mail attachment. I would definitely opt for a download-only scenario if that were available.

I am probably missing something, but as I understand it this feature is built in. Make sure every one of your PQs request the cache number maximum to be 501 or greater, and the only thing you get by email is confirmation when each was processed.

You're right. I have a PQ that has a max. limit of 1000, but it only returns 250 or so geocaches. The email notification does not contain the PQ. The cutoff is determined by the # of caches you specify, and not by the actual # of caches returned.

 

Edit : I'm mistaken, it is determined by the # of geocaches in the PQ, not by the limit.

Edited by Chrysalides
Link to comment

I am probably missing something, but as I understand it this feature is built in. Make sure every one of your PQs request the cache number maximum to be 501 or greater, and the only thing you get by email is confirmation when each was processed.

 

NOT TRUE ... if the PQ contains less than 500 caches it will come as BOTH an attachment and as a download ... so said the lackeys earlier.

 

This is the result I had this morning also. I had 4 PQs run, all requested 1000 caches, three were 990+ and the 4th was around 300.

 

I got three notifications for download and one email with attachment.

 

dave

Link to comment

I noticed the following, when testing the new 1000 caches PQ feature:

 

I ran a new PQ and it was quickly processed and shown on the "Pocket Queries Ready for Download" tab. Before downloading I decided to set the "Include Pocket Query name in download file name" flag for this PQ for the next time it is processed. But when trying to download the PQ from the download tab I got the message "the query is no longer available". After refreshing it disappeared even from the download list.

 

This was quite unexpected since I never downloaded the file (assuming it is available for one week). But in fact it is counted as a run PQ, but the download is lost in the gc dump :ph34r: .

 

So be careful: first save the PQfiles ready for download, then change settings in PQ.

Link to comment

15968: Trackable Map hops reversed

 

I do not see the benefit of this change as just the numbering was reversed. The fact that, on the trackable map page, the list of logs starts with the first and the numbering on the map with the last log is confusing :ph34r: .

 

Cheers,

FamWa

Link to comment

15968: Trackable Map hops reversed

 

I do not see the benefit of this change as just the numbering was reversed. The fact that, on the trackable map page, the list of logs starts with the first and the numbering on the map with the last log is confusing :ph34r: .

 

Cheers,

FamWa

I don't understand this either. The starting point for my coin is listed as "10" on the map, and its current location is "1". On the map page the logs are listed in chronological order, but on the trackable page they are listed in reverse chronological order. I think it makes sense to use reverse chronological order on both pages.

Link to comment

Hi,

 

first of all, thanks for the great job you did, I really like the new PQ features.

 

Still, the issue concerning the sorting of log listings is yet unresolved. Since this is obviously more complex than it seems, I'll try to give a decription of the problem as I see it:

 

First, as a minor point, the log listing on "Your Profile"/"Quick View". This is a mixed list of logs concerning both caches and trackables, sorted correctly by log date, newest on top. On the second level, that is, within one log date, it's sorted by object - sometimes caches first and TBs second, sometimes the other way round; all within the same list. The order doesn't just alternate, I cannot find a pattern.

On the third level, the logs of cache finds are sorted correctly (as I understand it): in the order I logged them, newest log on top. The sorting of trackable logs is the other way round: in the order I logged them, _oldest_ log on top.

As I wrote, this is a minor matter, but I think it may be connected to the second point:

 

Second, the log listing on a trackable page (e.g. TB3884W, my personal coin). The log listing itself is correct: 1st by log date, newest on top, then in the order the logs where entered, newest on top again. Now I click "View Map" and get a second listing from which the track on the map is derived. Here, the sorting on the first level is reversed (oldest on top), this makes the track run "the wrong way round", starting with my newest log numbered "1" (and ending with my first log). This reversal is only there since the recent update. On the second level, within one day, the order is reversed again; the _newest_ log is on top of the day.

 

Since the two levels of the list are sorted in different orders, the track on the map gets "loops" where a straight line should be. Instead of going like this:

 

2nd day, 4th log - 3rd log - 2nd log - 1st log -

1st day, 4th log - 3rd log - 2nd log - 1st log

 

it goes like this (now):

1st day, 4th log - 3rd log - 2nd log - 1st log (loop back)

2nd day, 4th log - 3rd log - 2nd log - 1st log.

 

Before the recent update, I think it "jumped" the other way round:

2nd day, 1st log - 2nd log - 3rd log - 4th log (loop back)

1st day, 1st log - 2nd log - 3rd log - 4th log.

 

So, the issue seems to be the sorting order of trackables within one log date being inconsistent with the sorting order of the log dates themselves. What was changed in the recent update was the sorting order _of_ the log dates.

(I hope I got that right :ph34r: - please consider that I'm writing this in Germany in a foreign language...)

 

Kind regards from Bielefeld/ Germany

Jens aka Teuto-Yachter

Link to comment

Second, the log listing on a trackable page (e.g. TB3884W, my personal coin). The log listing itself is correct: 1st by log date, newest on top, then in the order the logs where entered, newest on top again. Now I click "View Map" and get a second listing from which the track on the map is derived. Here, the sorting on the first level is reversed (oldest on top), this makes the track run "the wrong way round", starting with my newest log numbered "1" (and ending with my first log). This reversal is only there since the recent update. On the second level, within one day, the order is reversed again; the _newest_ log is on top of the day.

 

Since the two levels of the list are sorted in different orders, the track on the map gets "loops" where a straight line should be. Instead of going like this:

 

2nd day, 4th log - 3rd log - 2nd log - 1st log -

1st day, 4th log - 3rd log - 2nd log - 1st log

 

it goes like this (now):

1st day, 4th log - 3rd log - 2nd log - 1st log (loop back)

2nd day, 4th log - 3rd log - 2nd log - 1st log.

 

Before the recent update, I think it "jumped" the other way round:

2nd day, 1st log - 2nd log - 3rd log - 4th log (loop back)

1st day, 1st log - 2nd log - 3rd log - 4th log.

 

So, the issue seems to be the sorting order of trackables within one log date being inconsistent with the sorting order of the log dates themselves. What was changed in the recent update was the sorting order _of_ the log dates.

(I hope I got that right :ph34r: - please consider that I'm writing this in Germany in a foreign language...)

 

Kind regards from Bielefeld/ Germany

Jens aka Teuto-Yachter

 

Domo!!! und Guten Tag!

 

Great analysis Jens aka Teuto-Yachter!

 

Exactly what going wrong in the TB map page.

And Yes, I also think it got even worse after this update.

Very weird. One would expect it to not get better at lease, but not to turn even worse.

Hope it's fixed soon.

 

Thanks Lackeys & Hampsters!

 

Dr.MORO

Link to comment

10 Years! Events

 

PQ1K

 

Some specifics:

  • If you change nothing about the way you use PQs you will not be affected by this change
  • PQs requesting between 501-1000 caches will be available as a file download only, although we will still notify you by email when it is ready
  • PQs with less than 501 caches will be emailed as attachments and available as a file download
  • PQs will remain available for download a maximum of 7 days from the date it was generated
  • My Finds PQs are no longer sent as email attachments, but will be available as a file download

 

There's one bug:

[*] Pocket Queries with a space and/or dash truncate the filename when downloaded.

 

Example:

I name most of my queries something like "CA - Area of Interest" so that they sort nicely by state on the pocket query page. When I use the download feature, they come across as "#######_CA"(even without the zip extension) -- unchecking the "Include Pocket Query name in download file name" dialog renders it properly with the number dot zip. I suspect they need to URL-encode (or quote) the filename in the HTML header output.

 

Also...

 

It would be very nice for those of us who auto-process our Pocket Queries to make these retrievable via a unique URL (perhaps with some trivial authentication mechanism) so that we can automate the retrievals based on the email (you can even feel free to auto-delete the files after a successful retrieval if you're concerned about abuse potential (eg. share with your friends?)). Like many others (I suspect), I auto-save the attachments to a directory and then process those in to my own, personal (ie. not for anyone else's use but mine) database. The download link breaks that part of my process.

Link to comment

I tried running my usual query centered on my home coordinates in upstate NY. Everything worked fine except when I tried to preview it on the Google maps. A single cache (GCD) in Washington State was added resulting in a map being difficult to use. This cache did not show up in the list preview or in the download. I am using Windows 7 and Firefox version 3.63.

Team Taran

 

I'm glad I'm not the only one this is happening to. I have 2 queries for the Buffalo area for which I chose only New York and Ontario caches. One shows a cache in Illinois and the other shows a cache in California. I have not been able to find either of these caches in the list preview.

 

This has just happened to me as well. I previewed several PQs in the map yesterday, and this did not happen. However, today this is happening in several of the PQs that I previewed. It is always a single cache that is hundreds (sometimes thousands) of km away. Also, this "outlier" cache is not always the same cache. I have previewed the PQ at different times and sometimes the same cache reappears and sometimes a different cache appears. Most recently, I previewed a PQ for an area in Ontario, Canada and a cache in British Columbia appeared in the map preview. Very strange...

Link to comment

10 Years! Events

 

In this code update we have introduced a new event cache type called a "Lost and Found Event". For events which meet the criteria found on the Lost and Found teaser page, your local volunteer reviewer will update the cache type to this new icon, and the public profile of any cacher who attends one of these events will display the new cache type. This is your only chance to acquire a Lost and Found event icon, so find one near you and get your party on. :unsure:

 

Technically speaking: The Lost and Found event cache type is treated like any other Event cache type in the XML contained within a GPX file downloaded from Geocaching.com.

 

i do not know when this happened, but tonight i tried to access my profile page, my geocaches tab, and then the earthcaches icon to see the details...

 

instead i got all 626 caches...

 

i found the new icon that you referenced above...but...

 

as i clicked on each different type of cache icons - they all showed the total of ALL caches, and not the individual details...

 

why?

 

was this something you've changed? and i missed the notice? why?

 

thank you...

 

SuchaNana

Link to comment

Got another instance today of receiving an email notification that a PQ had run, but when I went to the download tab to download it, the file was no longer available and the page refreshed showing me with 0 files to download. This is a little confusing, since I just ran 5 PQs yesterday and downloaded 4 of the files (the other one gave me the "file no longer available" message yesterday). I thought the PQ's were supposed to be available on the server for a week, but now I have 0 files to download, even though I have run 20-30 PQ's in the last week...

Link to comment

Got another instance today of receiving an email notification that a PQ had run, but when I went to the download tab to download it, the file was no longer available and the page refreshed showing me with 0 files to download. This is a little confusing, since I just ran 5 PQs yesterday and downloaded 4 of the files (the other one gave me the "file no longer available" message yesterday). I thought the PQ's were supposed to be available on the server for a week, but now I have 0 files to download, even though I have run 20-30 PQ's in the last week...

Did you edit the PQs that ran?

Link to comment

I too am experiencing the random far-away cache issue on my PQ map.

The PQ does a 25 mi radius of Avon lake, OH and the random cache is GCAB2C located in the state of Washington.

 

The increase has allowed me to combine previous PQs and reduced the number than I need run for my preferences. Thank you for that.

Link to comment
Pocket Queries with a space and/or dash truncate the filename when downloaded.

 

Example:

I name most of my queries something like "CA - Area of Interest" so that they sort nicely by state on the pocket query page. When I use the download feature, they come across as "#######_CA"(even without the zip extension) -- unchecking the "Include Pocket Query name in download file name" dialog renders it properly with the number dot zip. I suspect they need to URL-encode (or quote) the filename in the HTML header output.

I too am seeing this bug: the zip file filename delivered at the download truncated at the first space. I am using Firefox under WinXP.

Link to comment

When I go to someone's profile page, then to the geocaches tab. When I click on for example, the multi-cache finds, or the unknown finds, I'll receive the search results for all cache types instead of the specific type. When I click on the finds side, I always get all finds not the specific find type. When I click on the hidden side, I get all hidden, not the specific hidden type.

 

This.

 

Both in Firefox 3.6.3 and in Google Chrome, i cannot view "finds/hides by type" from the profile page. In the past, i could click on the "?" icon in the finds column on my profile page, and the result would be a list of *only* mystery caches. Now, any time i click any individual icon on any profile page, the result is a list of *all types* of found or hidden caches.

Link to comment

When I go to someone's profile page, then to the geocaches tab. When I click on for example, the multi-cache finds, or the unknown finds, I'll receive the search results for all cache types instead of the specific type. When I click on the finds side, I always get all finds not the specific find type. When I click on the hidden side, I get all hidden, not the specific hidden type.

 

Yes, this is a problem for me also and it needs to get fixed.

Link to comment

When I go to someone's profile page, then to the geocaches tab. When I click on for example, the multi-cache finds, or the unknown finds, I'll receive the search results for all cache types instead of the specific type. When I click on the finds side, I always get all finds not the specific find type. When I click on the hidden side, I get all hidden, not the specific hidden type.

 

Yes, this is a problem for me also and it needs to get fixed.

 

Yep, this is new since the latest update. It needs to be on the to do list.

Link to comment

BUG

 

It's been mentioned in this thread before.

 

I have merged my 500 cache PQs into 1k PQs yesterday, then I deleted the old PQs but as before they appear striked-through and will hopefully disappear after their 24 hour since last run is over (one already did and the first 1k PQ ran for wich I received an email notification). I also saw that those old PQs where available for download but clicking on the link just made the link disappear one by one without the zip file being downloaded. The error message said the query didn't exist any more so I thought it's because I deleted those queries.

 

Today I clicked on the link for the first 1k PQ in the download tab and it happened again. The link disappeared, no file downloaded. The error message is: Sorry, the requested Pocket Query download is no longer available.

 

Now this is extremely annoying and definitely not connected with the original query being deleted. I didn't make any changes to it since it ran.

 

Just received the notification for the second PQ. Guess what, the same happened. Link gone, no download, same error message. Here is the link (copied before it disappeared): http://www.geocaching.com/pocket/downloadp...ba-adbac7125fe7

 

My PQs are named like this: All_Ireland_1:_01-01-2000_to_29-02-2008. I thought this should be ok. The settings are to include the name and to send as a zip.

 

I hope this helps and this bug is fixed soon. It is most inconvenient as I was just getting ready to use the bank holiday for some serious caching but now I cannot even update my GPS, not to mention GSAK. :P

 

abra

Link to comment

BUG

 

It's been mentioned in this thread before.

 

I have merged my 500 cache PQs into 1k PQs yesterday, then I deleted the old PQs but as before they appear striked-through and will hopefully disappear after their 24 hour since last run is over (one already did and the first 1k PQ ran for wich I received an email notification). I also saw that those old PQs where available for download but clicking on the link just made the link disappear one by one without the zip file being downloaded. The error message said the query didn't exist any more so I thought it's because I deleted those queries.

 

Today I clicked on the link for the first 1k PQ in the download tab and it happened again. The link disappeared, no file downloaded. The error message is: Sorry, the requested Pocket Query download is no longer available.

 

Now this is extremely annoying and definitely not connected with the original query being deleted. I didn't make any changes to it since it ran.

 

Just received the notification for the second PQ. Guess what, the same happened. Link gone, no download, same error message. Here is the link (copied before it disappeared): http://www.geocaching.com/pocket/downloadp...ba-adbac7125fe7

 

My PQs are named like this: All_Ireland_1:_01-01-2000_to_29-02-2008. I thought this should be ok. The settings are to include the name and to send as a zip.

 

I hope this helps and this bug is fixed soon. It is most inconvenient as I was just getting ready to use the bank holiday for some serious caching but now I cannot even update my GPS, not to mention GSAK. :P

 

abra

 

Quick update: I have modified my other 1k PQs and were able to download. It must be the "use query name" that breaks it. Without this option ticked it's fine. Also, with or without "send as zip" it's always a zip.

 

As long as the PQ name is used in the download tab I'm fine as I'm loading them immediately into GSAK but if I were to save the files I would prefer to have the name in it, so please do fix this bug.

 

The other bug in maps preview happens to me too: 1 odd cache on a different continent. I also noted that the maps are extremely slow to load. And yes, I also have a big difference between caches in maps view vs list view.

 

abra

Link to comment

Argh! :P

 

Another 1KPQ disappeared from the download list! Didn't delete, didn't edit, just refreshed the page...

The PQ was generated 2 days ago, so it should have stayed there for another 5 days...

 

This is very annoying so PLEASE fix the Bug or send us all PQs via Email again!

Link to comment

Argh! :P

 

Another 1KPQ disappeared from the download list! Didn't delete, didn't edit, just refreshed the page...

The PQ was generated 2 days ago, so it should have stayed there for another 5 days...

 

This is very annoying so PLEASE fix the Bug or send us all PQs via Email again!

I had this problem hit me on one of five PQ's last Friday, and then again on my one for Saturday, but late Saturday night I noticed that my entire queue of PQ's to download had been emptied (even the ones just run on Friday), and I haven't seen this problem since. I suspect that the transition may have needed the download staging area to be purged, and that is probably happened on Saturday evening. I am keeping my eyes on this, but it seems to have stabilized quite a bit over the weekend...

Link to comment

Hi Dr.MORO and everybody,

 

here I am getting home, starting the computer, logging the latest find, taking a casual look at my personal coin and what do I see? IT'S FIXED! :D:):mad::o TB order on the map page is correct, and so is the Path. Bliss!! :D

 

Thanks a lot to the crew

Jens (Teuto-Yachter)

Link to comment

I just ran my PQ for Portland Oregon, and each time I ran it, it came up with an off the wall, out in the middle of nowhere cache. I ran it several times, and tweaked the configuration several times, and it came up with differnet caches each time, once in Germany, once in Ft. Worth, one in Fire Island on the east coast, and one north of PDX near Mt. St. Helens. At this point in time the PQ is totally unreliable since I can't trust it to give me accurate results. FWIW, this PQ ran just fine yesterday with no problems. Very Frustrating. :D

 

Rich aka ivhs72

 

I'm still working on the cache that shows up in the middle of no where.. I have yet to reproduce this issue in an environment where I can do it repeatedly :D

 

-Raine

Link to comment

I'm still working on the cache that shows up in the middle of no where.. I have yet to reproduce this issue in an environment where I can do it repeatedly :D

 

-Raine

 

The 3 PQ's that I outlined in detail in this thread no longer pick up the errant caches on the map preview, however the number of caches is still inaccurate between the map preview and the list preview.

 

#1 - Map shows 728, list shows 793

#2 - Map shows 726, list shows 853

#3 - Map shows 726, list shows 851

Link to comment

ivhs72, just to verify.. this only happens when you "preview on map", correct? If you have a GPX file sent to you the data is correct?

 

-Raine

I just did a quick check on several of my PQs that ask for 1000 caches. It does not happen on every one, but does appear to return the same extra cache when I try it again. All but one of the extra caches were one, two or three digit caches. I did get on four digit cache. On one of the PQs I picked up GCF. These caches were all over the world.

 

You are more than welcome to spoof my account and take a look at those PQs. All are listed with similar names.

 

Edit to note that this is indeed preview on the map.

Edited by WeightMan
Link to comment

I'm still working on the cache that shows up in the middle of no where.. I have yet to reproduce this issue in an environment where I can do it repeatedly :D

 

-Raine

I noticed that the extra cache is always a very old cache, usually from 2000-2001. One of my previews even picked up GC14. I've previewed the map quite a few times looking for patterns, and the extra cache has always been from the first couple years of geocaching. Seems unlikely to be a coincidence.

Link to comment

Raine

 

I just verified that the problem still is there when I preview in the map mode (this time is was a cache in Bodga Bay California GC9C) but when I load the gpx onto my Garmin Oregon 550t, it does not show up. So the glitch appears to be site related, and is not really using that "phantom" cache. It also appears to that "phantoms" appear to be older caches, with only 4 or 5 digits in them. But then who knows what evil lurks in them..... the phantom knows..... :D

 

Rich

Edited by ivhs72
Link to comment

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.

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