Jump to content

RCH65

+Premium Members
  • Posts

    92
  • Joined

  • Last visited

Posts posted by RCH65

  1. Same problem here using IE11 and Chrome. In the main area, only the first message of a chat is being displayed. After sending a new message, sometimes the first message is being repeated - or nothing happens...

  2. There are lots of Letterbox and Wherigo cache types out there (at least here) having a puzzle to be solved to get the starting coordinates.

     

    I've never seen a Letterbox or Wherigo where you had to solve anything to get the starting coordinates. I did 40 Letterboxes and 16 Wherigos so far and have some on my "to do" list.

    I do all correcting in GSAK BTW.

     

    I just checked the latest ten Letterboxes I've found and four of them had a puzzle to get the starting coodinates:

    GC5JN3A

    GC5B1BJ

    GC4RXF0

    GC4QP12

    ...and so on...

     

    And yes... GSAK is an option but I'm not requesting an entirely new function - just remove the silly selection on cache types...

  3. And again...

     

    There are lots of Letterbox and Wherigo cache types out there (at least here) having a puzzle to be solved to get the starting coordinates. It's very annoying to add them manually to then GPSr as a waypoint because the link to the listing gets lost.

     

    Why not enabling "corrected coordinates" for these (or even all) cache types?

  4. I've requested a shunt to avoid ATT, Cogent and GTT on your CIDR. This should be active now, so please let me know if your experience has improved on your next attempt at browsing the site during a previous slow period.

     

    178.82.0.0/16 will now only use NTT, Qwest, XO or Zayo. You can view your outbound route from our infrastructure by visiting http://tracer01.Groundspeak.com

     

    I'm preparing a post so we can start collecting more evidence of the slowdown and identify which peer(s) is responsible for those of you affiliated with UPC.

     

    Hi Justin

     

    I've got all IP-Blocks of the Swiss Cablecom ISP here - a total of 63 (!) ranges registered at RIPE with netname CABLECOMMAIN-NET.

    Since I don't want to blow up this thread, shall I send this to you by mail?

     

    Greetings

    Ralf

     

    Wow... it's 17:53 and everything's quite fast - didn't have this for weeks. :rolleyes: Will keep monitoring...

  5. Have noticed this issue for 1.5 years. My browser tells me that it a 3rd party site that cannot deliver content. AKA: cloudfront, googleanalytics.

     

    These sites are heavily used will degrade the GC site.

     

    On a side note, Images from the gallery will not display sometimes. Don't know where they are hosted now (probably cloudfront)

     

    That might be... however, when accessing www.geocaching.com via VPN at the very same time (Office), the site is quite responsive but won't come to an end at home...

  6. Hi Justin

     

    I've got all IP-Blocks of the Swiss Cablecom ISP here - a total of 63 (!) ranges registered at RIPE with netname CABLECOMMAIN-NET.

    Since I don't want to blow up this thread, shall I send this to you by mail?

     

    Greetings

    Ralf

  7. Are you observing this slowness around the window of 18:00-20:00 CET or can you give an estimate? Do you know if your cablecom.ch IP is static or typically operates in the same CIDR? RIPEstats for your ISP do not appear complete, so I would have a hard time isolating possible networks for a workaround based on that information.

     

    Thank you for your investigations! Right now, it's about 23:30 CET and the webpage is still unreachable. That's why I'm currently using a VPN connection (via UK) to write this reply.

     

    Problems usually start in the region of 17:00-17:30 (CET) on working days and won't recover during the entire evening. On weekends, problems arise even earlier during the afternoon. We have a large number of users here, who are reporting the same issues in the Swiss Geocaching Forum. Most of them are Cablecom customers.

     

    My IP is not static but operates in the same CIDR:

     

    inetnum: 178.82.0.0 - 178.83.191.255

    netname: CABLECOMMAIN-NET

    descr: Cablecom GmbH

    descr: DHCP Scopes

    descr: Zuerich

    country: CH

    remarks: *************************************************

    remarks: For spam/abuse, please contact abuse@cablecom.ch

    remarks: E-mails to the persons below will be IGNORED!!

    remarks: *************************************************

    admin-c: LGI-RIPE

    tech-c: LGI-RIPE

    status: ASSIGNED PA

    mnt-by: MNT-LGI

    created: 2010-03-08T08:50:17Z

    last-modified: 2012-07-03T08:10:21Z

    source: RIPE # Filtered

     

    Greetings

    Ralf

  8. What I have seen is that the connection is extremely slow (unusable) as soon as "ntt.net" (Frankfurt->NYC->Seattle) appears in the TRACERT list. This always happens to me when connecting from my home PC (Cablecom Switzerland).

     

    ..snip..
    ae-10.r03.frnkge03.de.bb.gin.ntt.net
    ae-1.r21.frnkge03.de.bb.gin.ntt.net
    ae-3.r23.nycmny01.us.bb.gin.ntt.net
    Timeout
    Timeout
    ae-2.r04.sttlwa01.us.bb.gin.ntt.net
    ae-0.internap.sttlwa01.us.bb.gin.ntt
    border8.po1-40g-bbnet1.sef.pnap.net
    www.geocaching.com
    

     

    However, when using geocaching.com from my office (at the very same time via VPN) everything is quite fast and my route is using zayo.com for crossing the atlantic ocean - ending up at a different gateway of pnap.net.

     

    ..snip..
    xe-1-2-0.mpr1.fra4.de.above.net
    ae8.mpr1.fra3.de.zip.zayo.com
    ae4.cr1.ams5.nl.zip.zayo.com
    ae0.cr1.ams10.nl.zip.zayo.com
    v142.ae29.cr2.ord2.us.zip.zayo.com
    ae11.cr1.ord2.us.zip.zayo.com
    v11.ae29.mpr1.sea1.us.zip.zayo
    208.185.125.106.ipyx-072053-008
    border8.po2-40g-bbnet2.sef.pnap
    www.geocaching.com
    

     

    Seems that the guys at pnap.net should talk to their peering partner ntt.net...

  9. I think they've already changed it back to Unknown. I just downloaded a GPX of a puzzle cache, and it says "<type>Geocache|Unknown Cache</type>".

     

    Yes, they did... :rolleyes:

    And it's back to <type>Geocache|Mystery Cache</type> again.

     

    The MyFinds PQ still contains "Mystery Cache".

    Will you undo these changes or do we have to modify our scripts... ?

  10. You even changed "Unknown Cache" to "Mystery Cache" within the GPX file?

     

    Before:

    <type>Geocache|Unknown Cache</type>

    <Groundspeak:type>Unknown Cache</Groundspeak:type>

     

    After:

    <type>Geocache|Mystery Cache</type>

    <Groundspeak:type>Mystery Cache</Groundspeak:type>

     

    I guess, this wasn't your intention...?

     

    Since then, my GPSr (Garmin) won't show ?-Caches anymore.

  11. The PQ generator creates an invalid XML if there are Special characters (below X'20' ?) somewhere in the cache description. I don't know how they get into the listing, probably the owner used Copy&Paste. Example: GC4N77D

     

    This results in the following invalid data:

     

    <name>GC4N77D</name>

    <desc>déjà vu's „das war der Anfang“ #1 by dejavue7, Traditional Cache (1.5/3)</desc>

    <url>http://www.geocaching.com/seek/cache_details.aspx?guid=0e532090-104c-4e07-a501-c05ad8538a07</url>

    <urlname>déjà vu's „das war der Anfang“ #1</urlname>

    ..snip...

     

    Many (Garmin) GPSr stop importing caches at this point with the result, that you have just a partial Import.

    Even a full-blown XML Reader on a Windows system refuses to import this file.

     

    PS: After removing the red marked data, everything works as expected...

×
×
  • Create New...