renelm

Getting rather consistent 'Service unavailable'-messages again. Did the hamsters collapse? EDIT: .. and 5 minutes later, it seems to be ok again

I am getting a lot of 'Service not available' from the API server today when using GSAK. I cannot download PQs, refresh, get new access token etc. in GSAK. I tried removing my access token in GSAK, but can't get it back as I get a 'service not available' when trying to re-add it. The odd thing is, that GDAK on my phone happily refreshes data, downloads PQs etc. The full response I get in GSAK: ChilkatLog: QuickGetStr: DllDate: Aug 5 2012 UnlockPrefix: GSAKNEHttp Username: SEVEN:rene Architecture: Little Endian; 32-bit Language: ActiveX VerboseLogging: 0 QuickReq: url: https://api.Groundspeak.com/LiveV6/Geocaching.svc/GetAPILimits?AccessToken=(AccessToken} QuickGetToOutput_OnExisting: qGet_1: simpleHttpRequest_3: httpMethod: GET requestUrl: https://api.Groundspeak.com/LiveV6/Geocaching.svc/GetAPILimits?AccessToken=(AccessToken} IE_Proxy: gw.intet:3128 IE_ProxyEnabled: 0 Using existing connection to web server... -- BuildGetRequest -- IE_Proxy: gw.intet:3128 IE_ProxyEnabled: 0 Auto-adding any accumulated cookies. CookieDir: memory CookieDomain: api.Groundspeak.com CookiePath: /LiveV6/Geocaching.svc/GetAPILimits LoadCookieJar: Path: /LiveV6/Geocaching.svc/GetAPILimits GetDomainCookiesXml: CookieDir: memory Domain: api.Groundspeak.com HashKey: groundspeak_com.xml No cookies exist yet. --GetDomainCookiesXml --LoadCookieJar No cookie jar found. sendElapsedMs: 0 StatusCode: 503 StatusText: Service Unavailable Reading response body... No transfer-encoding header field. sslContentLength: 27 extraLen: 27 Already have entire response. readResponseElapsedMs: 172 --simpleHttpRequest_3 --qGet_1 --QuickGetToOutput_OnExisting --QuickReq responseSize: 27 responseContentType: text/html This is a text response... No charset specified, assuming Windows-1252 Converting to utf-8 charset. ConvertFromCodePage: 1252 NumUtf8Bytes: 27 Failed. --QuickGetStr --ChilkatLog

It should be stated, that we have the needed polygons etc. in case you (GC) need them

+1 and all that

1 hour and 20 minutes. Awesome responsetime - thanks guys

I just noticed that the little stat-bar on my personal profile doesn't work any more (and not for 2-3 others I just checked as well). My URL is: http://img.geocaching.com/stats/img.aspx?txt=View+my+profile&uid=c79b6bc4-ddca-46a3-8cf6-bedbf53e5e2e Opening that alone gives a Cheers

+3 from me as well - not that I have _that_ much need for it, but I can see how it could be helpful to people living close to borders and how it (possibly) could benefit Groundspeak by not generating needless traffic.

At the end of April I was with 12 other danes on a 2 week stay in California. Before I left DK I had planned that my 1000th cache should be found exactly 365 days after I found #1. Well, it didn't go as planned - in fact it went even better, so that I could log my 1000th cache on the 14th of april 2011 - 9 days before my 'deadline' - it was Howdy-Doo Hollywood - just below the Hollywood Sign

.. and all around the world (we see them in DK too) Or a smartphone and not verifying the coordinates on google maps.. I became FTF on a cache that was placed by someone who got the coordinates with an iphone and didn't bother to uncheck 'this cache is published' to make sure the coordinates were correct when he entered them in an incorrect format and ended up having GZ roughly 1900 feet off (!).

Clever! The video does not state what her response was though, but I assume it was a 'yes'? For the geocaching-part, I'd like to comment.. at the time of shooting the video and up until the last step she didn't know it was a 'mock' cache.. so why are you carrying the first step containers with you? Cheers!

Wow.. PQ's with long titles make the PQ-page look reaaaaally funky now. I sure hope this fixed-with-fad is just a temporary phase. There are people out there with monitors that can do more than 900px horizontally you know...

Hence the term 'beta'. Well.. I'm all for having a beta-map to get all the kinks out.. but it shouldn't be as a replacement for the old map (which it is now after the site is up again). I do see though, that PMO-caches are shown in the correct spot for me (I'm a PM), so that's.. better. Now it would be nice if they'd added a little 'this is what PMO-caches look like'-icon in the legend along with the other caches in the filter-section.. and made it possible to make the personalize-option remember my setting.. Oh well.. it's a huge step forward, having the PMO-caches on the "not so beta that we can't use it as the primary map"-map now

I see a lot of good little fixes on the list, but: "* Premium Only caches will display for all users on Beta Maps, with coordinates slightly obscured". As a PM I am not happy - it sounds to me like the beta was published a few months too soon when it still isn't able to distinguish between who's looking at it as a PM or not.. (unless you forgot to add '.. except for PMs, who will now see them in the correct position'). The map is part of a very essential part of the site, but in the past month I've had to resort to using the google maps macro in GSAK for a reliable map..

I don't know if this is related to this update. If it isn't, please refer me to the correct to place this. I just noticed tonight, that when clicking through several pictures uploaded to one log, when using the back and forth-arrows, the 2nd picture have their proportions broken. I asked on the danish forum if anyone else had seem this or if it was just me, and others have seen it too.. As a 'bonus', when hovering over a link to an image for a log, the title/alt-text shows a _lot_ of rubbish. See the attached images: 'Garbage' in the title/alt-tag First picture is ok. I hover over the 'forward'-button the image: 2nd picture is shown with distorted proportions: 2nd picture again, as it looks when clicking on it directly: The cache in this example is: http://coord.info/GC2E8ZE EDIT: Forgot to add, that I am (still) using Google Chrome on Windows 7. I can't say for the other users. I just tested in IE though, and there it seems to work just fine - still garbage in the title/alt-tag though..

.. aaand I just reproduced it. Next time I'll time how long it takes for the map to 'forget' that I am logged in.

+2 on the map issue. This time I got a screenshot. I've had the map-window open for a long time. Just changed it to sat-view and moved the view around a few times when I noticed that my finds and my own caches no longer were marked as such. F5 solved it (for now). See attached screenshots: I'm logged in, but caches are shown displaced and marked as 'not found' F5 resolves it.. I am on windows 7, 64 bit using Google Chrome. I have an idea though. One 'sub'-session regarding the map is timing out, even though we're still logged in, making the module that refreshes the map think we're not logged in after long time of inactivity? This seems true for what I've seen.. it has only happened when I haven't done anything on gc.com at all for a while and happened to have the map-window open. EDIT: click on the images for a slightly larger view..

I saw this as well.. The foound-but-marked-as-unfound-caches were even slightly offset on the map compared to their real location. I closed the window and re-opened it and haven't seen it since though..

I don't know if this is something that has happened with this udate (I use the route-function very seldom), but.. there's a weird behaviour of the route used for the query on the map preview page now. See this image: In the image to the right is the route used for the PQ. In the big picture is the resulting PQ - showing caches found along the route just fine, but.. the route itself suddenly cuts off and heads south along the way. Now, since the PQ does seem to find caches along the actualy route, this is not a *critical* error.. just very odd. I'm using Google Chrome, if it's any help

+1 It looks kinda funny in GSAK..

double-post (bleep'ing proxy at work playing tricks on me)

I surely hope this fixes the issue with thwarted linefeeds in field-notes pre-typed in GSAK that are uploaded.. Can you confirm that this is on the list as well? Going through each log to fix this gets pretty old already after the 2nd one.. how about letting us who don't care about a fancy WYSIWYG-editor go directly to the raw editor? Cheers EDIT: In GSAK, the html from the commets in the GPX-file is also now visible for caches that have been logged after the update. Sigh.. I can see why saving the formatting in the DB right away gets better perfomance when viewing the entries, but man, oh man, this breaks so many things..

Just checked 2 caches I own - one is active and another one I am working on and.. ow!.. I have list of things in a <ul><li>...</li></ul>-style, and now the editor has added liberal amounts of <br>-tags everwhere - even in the middle of sentences that belongs to one paragraph in the rest of the text.. :/ Makes the cache description look like modern prose with these random linefeeds ... Not cool GC..

Awesome.. has it happened yet? Because.. I just tried re-uploading a field_notes files and .. linefeeds are still stripped in the editor so I have to re-enter line-feeds before submitting my logs :/

I was just getting my blood pressure up about this one.. editing field_notes.txt before uploading it from my gamin I use a lot of newlines that then got stripped after uploading it to the site.. I hope fixing that is what this means.. The proper formatting is back for existing logs though, which is nice..

Same for me.. I can even tell the difference between a pre-update log and a post-update log.. (screenshots will be provided if neede). Loads of white-space going to waste there..