Can't log in

[+psychocyclist]

I haven't been able to log in for about a week with my usual user id ('psychocyclist'). I have tried it from several different computers using different ISPs, and I always get the same error ("runtime error" is the page title. The message on the page starts with "Server Error in '/' Application.)

 

I am able to use my id to log into the forums, and I am still receivingi PQ updates by email. I just can't login to the site to change anything or to log finds.

 

I was able to create a new id and it works fine. This would indicate that the problem is not with my browser, computer, or ISP, but rather something about my account in the GC databases.

 

Any help would be appreciated.

[+Allanon]

Did you email contact@geocaching.com for assistance?

[+psychocyclist]

Did you email contact@geocaching.com for assistance?

 

Yes. They suggested it was a dns cache problem. I created a new account which worked fine, showing that it was not the cache. I have sent a followup to the contact address but not heard back.

[OpinioNate]

Did you make any profile changes recently? Perhaps some custom code in there? I've seen this happen to some accounts when malformed code is added to caches or profiles. I'll have to get a dev to dig into your account and get back to you.

[Jeremy]

I haven't been able to log in for about a week with my usual user id ('psychocyclist'). I have tried it from several different computers using different ISPs, and I always get the same error ("runtime error" is the page title. The message on the page starts with "Server Error in '/' Application.)

 

Thanks for bringing this to our attention.

 

We investigated the issue and you should now be able to log in. However, it seems that the error uncovered some unusual activity with your account which seems to indicate you are using an automated program to do something. Presumably this application is scraping the web site which is a direct violation of the terms of use.

 

It would be helpful to us if you could let me know why your account has this unusual behavior. As far as I know, no user normally logs in to the web site every 13 seconds over 30,000 times in a month. You can understand that our site isn't really designed to support this kind of activity - nor should it.

[+StarBrand]

I haven't been able to log in for about a week with my usual user id ('psychocyclist'). I have tried it from several different computers using different ISPs, and I always get the same error ("runtime error" is the page title. The message on the page starts with "Server Error in '/' Application.)

 

Thanks for bringing this to our attention.

 

We investigated the issue and you should now be able to log in. However, it seems that the error uncovered some unusual activity with your account which seems to indicate you are using an automated program to do something. Presumably this application is scraping the web site which is a direct violation of the terms of use.

 

It would be helpful to us if you could let me know why your account has this unusual behavior. As far as I know, no user normally logs in to the web site every 13 seconds over 30,000 times in a month. You can understand that our site isn't really designed to support this kind of activity - nor should it.

 

Its always nice to see a few facts.

[Mushtang]

I haven't been able to log in for about a week with my usual user id ('psychocyclist'). I have tried it from several different computers using different ISPs, and I always get the same error ("runtime error" is the page title. The message on the page starts with "Server Error in '/' Application.)

Thanks for bringing this to our attention.

 

We investigated the issue and you should now be able to log in. However, it seems that the error uncovered some unusual activity with your account which seems to indicate you are using an automated program to do something. Presumably this application is scraping the web site which is a direct violation of the terms of use.

 

It would be helpful to us if you could let me know why your account has this unusual behavior. As far as I know, no user normally logs in to the web site every 13 seconds over 30,000 times in a month. You can understand that our site isn't really designed to support this kind of activity - nor should it.

 

Its always nice to see a few facts.

It makes me wonder if he soon won't be able to log in again... ever.

[+psychocyclist]

Thanks Jeremy for fixing this for me.

 

Yes, I had run a macro which I now see was a "bad" thing to do. I haven't run that macro in about a month and obviously won't be running it again.

 

Since you asked, here is how the multiple requests came to be. Note that I am providing this to respond to your request, not to complain:

 

The macro in question was meant to deal with updating my local database for what was supposed to be a few archived caches. While PQs send information on active caches, the GPX files never include information on archived caches. Without some way to deal with this, it's inevitable that you'd end up visiting previously archived caches. The macro was meant to get GC for information on 'old' records in the local database that didn't get updated in the last couple of weeks despite the fact that they matched the PQ filter set up on GC.com (presumably, these are the archived caches). However, when my PQ list changed, this mechanism broke.

 

I'll have a look at the forums to see how others deal with archived caches. It would be nice if they continued to show up in PQs for a couple weeks after being archived so that they weren't such a nuisance to deal with.

[+StarBrand]

Thanks Jeremy for fixing this for me.

 

Yes, I had run a macro which I now see was a "bad" thing to do. I haven't run that macro in about a month and obviously won't be running it again.

 

Since you asked, here is how the multiple requests came to be. Note that I am providing this to respond to your request, not to complain:

 

The macro in question was meant to deal with updating my local database for what was supposed to be a few archived caches. While PQs send information on active caches, the GPX files never include information on archived caches. Without some way to deal with this, it's inevitable that you'd end up visiting previously archived caches. The macro was meant to get GC for information on 'old' records in the local database that didn't get updated in the last couple of weeks despite the fact that they matched the PQ filter set up on GC.com (presumably, these are the archived caches). However, when my PQ list changed, this mechanism broke.

 

I'll have a look at the forums to see how others deal with archived caches. It would be nice if they continued to show up in PQs for a couple weeks after being archived so that they weren't such a nuisance to deal with.

 

You actually mention the solution above.

 

If your PQs are based on date placed - then they are static as to what caches they will contain with the exception of archived caches. It becomes very easy to assume that after you update GSAK - any caches not updated must therefore now be archived.

GSAK has a column telling you what caches were not updated with the last PQ.

 

Keep in mind that Jeremy and the good folks up at HQ are on record stating they never had any intention of supporting anybody's offline data.

[+benh57]

Another good way is to use the new GSAK 'check email' macro. I set up a secondary gmail account which gets instant notifications of all geocaching archival/ un-archival notices within 100 miles. The GSAK macro can be set to check this email address and update your db's status fields. This is totally allowed since it doesn't touch Groundspeak's servers.

[+psychocyclist]

It becomes very easy to assume that after you update GSAK - any caches not updated must therefore now be archived.

 

Understood, but this means that logs that have been submitted on archived caches since the last successful PQ will never be downloaded. I can learn to live with this despite its 'incompleteness'.

 

Keep in mind that Jeremy and the good folks up at HQ are on record stating they never had any intention of supporting anybody's offline data.

 

Of course -- it would be impossible for GC to support everyone's ideas of what their offline data needs would be. However, offline tools generally allow more flexibility in viewing/searching the data than GC does natively.

[Mushtang]

If your PQs are based on date placed - then they are static as to what caches they will contain with the exception of archived caches. It becomes very easy to assume that after you update GSAK - any caches not updated must therefore now be archived.

You know what they say about assuming, right? Any cache temporarily disabled for a few weeks would get deleted because you would assume it's archived.

[+Tequila]

If your PQs are based on date placed - then they are static as to what caches they will contain with the exception of archived caches. It becomes very easy to assume that after you update GSAK - any caches not updated must therefore now be archived.

You know what they say about assuming, right? Any cache temporarily disabled for a few weeks would get deleted because you would assume it's archived.

 

Not true. A date placed PQ will still update that cache because it is still active. Archived caches are different.

[Mushtang]

If your PQs are based on date placed - then they are static as to what caches they will contain with the exception of archived caches. It becomes very easy to assume that after you update GSAK - any caches not updated must therefore now be archived.

You know what they say about assuming, right? Any cache temporarily disabled for a few weeks would get deleted because you would assume it's archived.

Not true. A date placed PQ will still update that cache because it is still active. Archived caches are different.

See, I was right about what happens when one assumes.

 

I assumed that he meant that the PQ would only show caches updated in the last 7 days... but now I understand better as to what he was suggesting.

 

My bad.

Edited October 26, 2009 by Mushtang