MaxB on the River

We have started running into problems with finding TB's with photos as part of the TB Name. We understand it looks nice, but causes problems when dropping from inventory into caches Because the photo text code is stored in the TB inventory box under the cache log it now extends the drop box choice wider than the screen. If long enough when you scroll (left to right) to see the scroll bar (up and down) to try to find the TB you want to drop, you can no longer see the names of the TBs on the left. So you can't scroll and choose the TB's you want to drop. This is even the case if you are using the smallest possible font choice for your browser. Is there a way to limit the width of the TB inventory drop box so this doesn't happen? I know it will cut off the remainder of the text for a TB, but if set correctly would only affect those where a picture is attached. It took us a while to understand why sometimes the drop box was wider than other days. We ran into the biggest problem where we had to contact the TB owner about removing the picture so we could drop TBs. The photos are also causing problems if they are left very large in the Inventory on the My Account page, as it again changes the width of tables. I enjoy the photos, but you can also see them if you look at the TB page itself instead of adding it to the title.

We are trying to clear some space in our watchlist (because we've hit the limit again) for travel bugs. We click the remove but, then get the verify deletion notice with the Yes button. However when we click the yes button we get the following error message. Unable to validate data. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.Web.HttpException: Unable to validate data. Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace: [HttpException (0x80004005): Unable to validate data.] System.Web.Configuration.MachineKey.GetDecodedData(Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Int32& dataLength) +196 System.Web.UI.LosFormatter.Deserialize(String input) +60 [HttpException (0x80004005): Authentication of viewstate failed. 1) If this is a cluster, edit <machineKey> configuration so all servers use the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster. 2) Viewstate can only be posted back to the same page. 3) The viewstate for this page might be corrupted.] System.Web.UI.LosFormatter.Deserialize(String input) +118 System.Web.UI.Page.LoadPageStateFromPersistenceMedium() +102 [HttpException (0x80004005): Invalid_Viewstate Client IP: 24.11.233.13 Port: 1414 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ViewState: shortened the error message for space. Removing items one at a time from the watchlist is very frustrating as it is doing it one at a time. It is even more frustrating when we keep getting error messages and have to start over.

Email watchlist notification stopped at 12:42 pm today and we have Comcast, haven't received anything except 1 contact from cacher through GC. Sure hope the problem gets fixed.

We are also hoping for check boxes to be added so bulk deletions can be done on watchlist items. We watch many of the TB's that we have moved and would like a much easier way of removing them than 1 at a time. Hope this gets looked at soon.

I was receiving email notifications through 1:52 pm EST today and have gotten nothing since then. Just wondering if anyone was aware of the problem.

We have received no watchlist TB or owned Sunday event cache notifications since around 10pm EDT last night. Hope it gets fixed soon.

It seems that most of the TB's that we picked up from Midwest Geobash on 7/9 and dropped again the same day haven't recorded their mileages as of yet 7/12. I thought they were supposed to update on a daily basis. Were there sever problems on 7/9? the mileage problem continues for those we dropped on 7/10 as it hasn't updated those logs either. Thanks for checking into the problem.

The cacher can go back in and grab the TB back and log it into the cache where they left it. By backdating before your grab date, it puts the logs in the correct order. This does take it out of your inventory however, you then need to go back in and grab the TB again. You can then go back and delete the last grab log and the TB will stay in your inventory ready for you to drop.

I like the feature in the upper right corner where you can change how many caches are listed per page up to 50. My earlier problem seemed to have cleared up right after my post. Thank you.

This morning I tried to get into my bookmark list and check caches for updates. It has 3 pages of listings, however when I click on each page the same page information appears. Last night it worked just fine, now it doesn't. I hope that we don't have to download each page for PQ's. I liked the feature of being able to download into 1 file all the caches in a particular bookmark. AS there is no way to build a PQ through normal means to select caches listed in a bookmark list.

Thanks Jermey and Raine for all your work on trying to get the TB miles corrected. We will just be patient until the nightly scheduled updates are completed. I know this has been a long process trying to get the kinks worked out. Thanks for all of your hard work.

Jeremy, How often does the schedule run for updating TB miles? In several of the TB's we are trying to figure out mileage, we have some that seem to calculate correctly, but in others not all of the placements show any mileage. Many of the TB’s we have dropped seem to not have mileage calculated since 1/12 through 2/11. EX: Tarpon Springs TB: the last mileage updates was 1/5. There have been 2 retrievals and placements since then, the last being on 2/11. Still no mileage showing up for those movements. http://www.geocaching.com/track/details.as...3a-f92433acb9ee Another example: TB Mickey The Tour guide http://www.geocaching.com/track/details.as...24-5186a9a7713c I also noticed that it doesn’t seem to update the mileage of the TB’s always correctly on the TB owners trackable page. EX: Geo-Funk has 4 TB’s still listed as 0 miles on trackable page, however if you go to the TB’s T&T race bugs, they all show miles on the individual TB page. http://www.geocaching.com/track/search.asp...73-3af2a82122c9 Hope this helps in trying to find the glitches. MaxB

I know that GC is trying to fix the TB mileage problem and the last 10 days must be just as frustrating to the staff as it is for the members. But many people we talk to including ourselves like to be able to look through the TB logs without having to go through lots of pages to do this. Since the TB mileage problem is because all of the logs are now paged. Perhaps it would be better to return to the old method of displaying. It seems the problems with logging TB drops and pickups is because of this same issue. I know that this was intended to improve the loading of TB pages, but it seems to be causing just the opposite problem and frustrations for everyone. I'm sure everyone would be willing to wait a little longer to load a TB page, then continue with the same problems.

We are looking forward to the TB miles being fixed as well. We know they are working on it to try to solve the problems. We also believe having a "show all" logs feature would be nice, particularly for TB's that want to travel to states. It is cumbersome now to glance back through each page to determine if they had been to a state or not. This helps us decide if we can take it farther or is a good candidate for leaving for another TB trade. I even went to the TB map of movement to see if it would easily show me the states, however it lists caches but not the state where the cache is found. We certainly liked the other improvements accomplished with the last updates and know system bugs will be worked out. Thanks to the Groundspeak crew!

Thanks Jeremy, I was having the same problem as others, however my error meesage had to do with a Date field was trying to enter a NULL value. Even when I went in and made sure the cache log date was chosen (not just the default) I received the same message. Looked like it just wasn't accepting that date for the TB Drop. I just tried dropping Tb's and it is functioning again. Thanks

In editing one of our TB's pages, I noticed that the Bug Image dropdown listing. It showed a list of all the pictures in the Tb's gallery. I assumed that if I choose one of these images, it would then become my defualt image. (Seemed like a really nice feature without having to upload a copy of a picture already in the gallery and make it the default). I ran into a problem. Either I get a server error with a choice that says "The image can't be found or doesn't exist". OR I get a new picture as the default, but a random picture from some other TB's gallery. Someone may want to check into this feature. I think it would be great to be able to change my TB's default image to a nice one that another cacher may have taken without having to upload another copy to the serve. If you need a test you can use our Albert the Gator (TBE47B). This is the only one I have tested on and it doesn't work. Thank you

Thanks Jeremy, Appreciate your help in rolling back until a better fix is worked out. A separate current history would be nice and it could give more information like the bug history does currently.

I can understand wanting to limit the number of TB's shown on cache pages, however, now in order to find out what TB's are currently in a cache, you have to search through the entire bug history. None of the sorts will provide you with the bugs currently in the cache listed together. This can be very difficult on Travel Bug hotels, as there may be 15-20 or many more pages. Perhaps a fix to this would be in increase the number of TB's listed to a maximum of 10-15. OR Allow users to sort by location so all the TB's in the cache would be listed together. OR Default the listing sort so that those found in the cache currently are listed on the first page of the history. For example: In the cache link listed below there are currently 14 TB's registered in the cache because we just placed them there yesterday. http://www.geocaching.com/track/search.asp...4b-70a66afc7a24 In order to find that out now - you have to click and view through 7 pages to determine that information. What happens to a very active TB hotel/motel cache that may have 50 pages of TB's logged through it? It makes it very difficult for those cachers who move TB's around the country to now have to take the time to look through all of the Bug history pages to figure out how many are present and information about TB's they may be trying to help move. We have enough problems trying to help new people understand how to log TB's when they can see them listed on the cache page. If they can't even find the TB llisted, then many more TB's are going to come up missing. This is going to result in very disappointed TB owners, that will stop putting them out. Sure hope GC thinks about my suggestions, as the current listing seems very difficult to use and not user friendly, especially for newbies. Thanks.