Basecamp horribly unreliable, Garmin have you no pride?

If I had known at the start you were having problems with Trip Planner I would have mentioned that, in my opinion, that feature of Basecamp is horribly buggy to the point of being, to me anyway, useless.

Me too....never use it. I just create a new list and put whatever I want in it for a trip.

Me too....never use it. I just create a new list and put whatever I want in it for a trip.

Me too, up until trying out basecamp for the first time this week. In this case, I was planning a multi-day sightseeing trip that would include other people. I have always done this with mapsource (and/or oziexplorer) making waypoints and daily routes. But when I first loaded Basecamp, in addition to dealing with the awkwardness of the differences in interfaces, I was drawn to Trip Routing because it added the ability to specify times at various Points Of Interest (not just transport times) and to generate a single PDF files with a summary of each days planned schedule. So it is a nice feature, too bad it is so buggy.

I have had basecamp crash one time since eliminating the mixture of standard and custom APs. But have not had time to investigate (bug report sent to garmin). Since all my work has been done through the Trip Report interface, the other crashes could be associated with that feature. I have not found a way to create routes outside of trip report, then insert them into a day's schedule, so I am stuck going through Trip report. Unless I abandon it entirely, itn which case there is no reason for me to use Basecamp instead of Mapsource, and interface after years of use I find much more intuitive.

...I have not found a way to create routes outside of trip report, then insert them into a day's schedule, so I am stuck going through Trip report...

You are not stuck with Trip Report; Basecamp routes can be printed via a pdf printer driver... or exported and the data parsed outside of BC.

Personally, I extract the data and create my own trip reports.

In response to the information I sent, I got a reply from Garmin I was not pleased with.

As a BaseCamp developer, I'm pleased to hear that some people in this thread rarely see BaseCamp crash. We do take the quality of BaseCamp very seriously. However from our analytics and error reports, we know that there are occasional issues with BaseCamp. We do our best to resolve the critical issues, but we don't have infinite time or resources for development and test... so some issues will undoubtedly make it out into the field.

I know you contacted support with details about the error that you saw, but if you can provide additional details here I can see if I can offer any insight or help (and hopefully fix the issue in a future version).

... However from our analytics and error reports, we know that there are occasional issues with BaseCamp. We do our best to resolve the critical issues, but we don't have infinite time or resources for development and test... so some issues will undoubtedly make it out into the field.

I know you contacted support with details about the error that you saw, but if you can provide additional details here I can see if I can offer any insight or help (and hopefully fix the issue in a future version).

Given the more recent posts, it appears there are signficant issues if one tries to use the Trip report feature ("horribly buggy to the point of being, to me anyway, useless)". And while what you say is true about anyone providing software, that infinite time and resources are not available to test, that can also be an excuse for allowing the release of horrible buggy software. Within two hours of loading Basecamp, it crashed and I was not doing anything "exotic" (unless you call using trip reports exotic). That is not a good sign that extensive testing was done. And as an educator and software developer with over 40 years experieince, ANY crash of a software product is a bug (although the bug may be caused by system software and not the application code). I do not know what I can add in addition to what I stated above about the one specific problem that was repeatable. The bug report was sent to garmin and I do not have any idea if/how that information would still be found on my system. For the other crashes, I sent crash reports thinking that was all that was needed to address the issue. (To paraphrase, I also do not have infinite time. I did send the reports, anything beyond that requires time and in too many cases with various companies, I have found that time was wasted as any additional information just disappeared into a black hole.)

My purpose behind this thread was dealing with the obvious serious bugs, those that cause crashes. But since you asked, after just a few days use I can offer you some of the minor things that I think it is clear are "mistakes" but just annoynaces that make use of the product a pain. One of those things that get classified as "its not a bug, its a feature" as the old saying goes.

1. In trip report, one can associate times with a waypoint. When entering the time and displaying it on the same screen, one time zone is used. Look at the information on a different screen and a different time zone is used if the waypoint is not in the same tz as the computer. Example, I create a waypoint for somewhere in california and enter an arrival time of 8:00am on my computer running on EST. No TZ can-be/is specified, one just enters/sees 8:00am associated with that california waypoint. But go to another screen (Advanced) and that arrival time will have changed to be 5:00am. I will not quibble over a decision to interpret that time as the computer's TZ or the waypoint's tz, but which ever the software chooses, it should be consistent in both places.

2. With each waypoint in a trip Report schedule, one can specify the interval stayed at that waypoint. If nothing is entered, the deafult is 30 minutes. This is true with all except the first and last waypoint in a daily schedule. All that makes sense. But when one outputs the daily schedule, each days gets 30 minutes added because the final waypoint has no interval associated with it and the software adds in the 30 minute default. When entering the final waypoint, one cannot explicitly say its interval is zero because the software does not include that option for the final waypoint, because an interval does not apply. But then 30 min gets added upon printing the days schedule.

3. Lets say you create a daily schedule with enough waypoints so that the list is long enough so all waypoint for that day are not visible in the limited window space (given each waypoint takes up over 100 pixels of vertical space, one does not need that many waypoints for this to happen). lets say one needs to make a chnage in a waypoint toward the end of a days schedule. One must first click on the waypoint to highlight it. But doing so triggers the software to rescroll the screen so the first waypoint of the day is at the top of the screen. So the software scrolls away from the waypoint you just selected and one must then re-scroll back to that waypoint.

Let me repeat, these are not system crashes, they are annoyances that one can work around. But they are not indicative of high quality work. Not the kind of qulity that matches the generally high quality I have found in garmin's hardware. Not the kind of quality I would find aceptable if I worked for garmin.

Points 1, 2 and 3 are bugs reported here months ago.

If the steps taken to produce the crash were posted here first - then "repeatably" would have been proven.