renelm
-
Posts
42 -
Joined
-
Last visited
Posts posted by renelm
-
-
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:
Opening that alone gives a
"Server Error in '/' Application.The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Requested URL: /error/error.aspx"
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
-
Not just summer. There are noobs created all year round.
.. and all around the world (we see them in DK too)
By using Google Earth to set your coordinates.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...
-
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..
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..
-
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.
.. 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..
-
Hi,
since the update, the maps site is broken in regards, that after some time, suddenly all found caches are shown as unfound.
It's quite easy to reproduce:
- Go to the maps site with your home coordinates as start point
- Hide all found and your own caches by selecting the check boxes
- zoom out 2-3 levels, move around
- click on the "hand" in the left top circle ("back to last result")
Now all caches are shown as unfound. There are quite some more ways to get this effect, but this is the most reliable way to reproduce.
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
-
are there any plans for removing the HTML from logs downloaded through GPX, even if/when the HTML editor makes a comeback? i can see a lot of potential havoc caused by this.
+1
It looks kinda funny in GSAK..
-
double-post (bleep'ing proxy at work playing tricks on me)
-
We are rolling back the HTML editor for cache logs.
This should happen today. In the next dev cycle we're going to review the decision to implement this editor in the logs and perhaps re-release with modifications. Thanks for your patience over the last 24 hours.
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..
-
Could you please PLEASE stop making my cache listings look WORSE after EACH new "fix"?!? Now <br /> tags are very liberally added, at places were they don't belong and were I definitely didn't type them in my description!!
Now _all_ my listings looks like an absolute mess :-((!
For the sake of an example, look at GC25G1C. The description input field in the cache edit page breaks long lines into two (as it had before) - and the rendering code inserts <br> tags at each of these line breaks in the editor! This is absolutely ridiculous.
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..
-
The hotfix is almost ready and the site will be going down shortly. We managed to get almost everything fixed:
...
-Line feeds stripped from cache log formatting
...
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 :/
-
We're putting together a new build to push live shortly. These cases will be put to bed:
...
-Line feeds stripped from cache log formatting
...
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..
-
Though still, lots of space between the log date and the log.
Thanks!
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..
API: Service Not Available, but only in GSAK
in Website
Posted · Edited by renelm
Getting rather consistent 'Service unavailable'-messages again. Did the hamsters collapse?
EDIT: .. and 5 minutes later, it seems to be ok again