Related

Erase trackpoints from historical Track in BaseCamp 4.3.4 too slow

AnkEric
Erase trackpoints from historical Track using BaseCamp 4.3.4 (remove glitches, gps drift when not moving, user driving in the wrong direction, stops etc.): to remove each single trackpoint takes 1-2 seconds!
In previous BaseCamp version 4.2.5 I was able to erase multiple trackpoints within one split second.
(Is BaseCamp recalculating track length after each single erase? Not very effective and very irritating).

Update:

Last night I had to clean-up 8 tracks (bicycle and walking). It took me one hour (normally 15-30 minutes), and after half an hour I decided to use MapSource as a work-around.

I tried to reproduce the issue, but I failed to do so. Trackpoints were erased in the same split second as before.

Why? How?

If the GPS (Etrex 30) is not connected to PC/BaseCamp in Mass Storage mode there is no problem.

If the GPS (Etrex 30) is connected to PC/BaseCamp in Mass Storage mode than the performance issue is reproduced.

To resolve: Eject device, restart BaseCamp and performance in erasing trackpoints is ok!

I was not editing a track on Device. The track was being sent from GPS to BaseCamp List and edited in BaseCamp List. There is no real need for GPS to be connected, but I prefer having GPS available.
Number of Archived Tracks on GPS: 10 tracks.
Looking back I think accessing GPS slowed down performance even more (up to 3 seconds per trackpoint). But that's not a fact, just an impression.
  • 0
    Not seeing any of that so it's probably a problem with your PC somewhere. Apart from an uninstall/reinstall I'm not sure what else to suggest.
  • Former Member
    0 Former Member
    No problem, I'll give it a go. I'm not very computer savy so maybe you could tell me what I need to do to preserve my data.

    Thanks.
  • Former Member
    0 Former Member
    Uninstalled and reinstalled. Hasn't made a bit of difference. Installed on other PCs but on them Basecamp recognizes Oiltrax map on the device but won't show it. Beyond infuriating and hours wasted because of this update.
  • 0
    The issue is hard to reproduce, but it's still existing. Also in BaseCamp 4.4.1 although even harder to reproduce.

    Not relevant:
    1. - Nothing on PC running in the background, no services (except for all the normal processes).
    2. - No PC problem (since starting this thread I have reinstalled Windows, clean install, due to hard disk replacement).
    When the issue occurs there is never more than 35% CPU usage and never more than 20% Memory usage. So this is not a PC performance related issue.

    Recent history:
    9/25/2014: working on 20 holiday tracks and the issue occurred almost all day.
    Work-around: Exit, Restart BaseCamp. It will now take some time before the issue is back.
    9/25/2014: I have red post by PUGNUTS: "I'm having the same problem. Driving me crazy".
    9/26/2014: trying to reproduce. First no success.
    9/26/2014: reproduced...!

    Process indentification:
    1. - Deleting Trackpoints is a CPU consuming process: 2 to 35% CPU. But the amount of CPU being used does not (necessarily) show MousePointer. The issue might not occur even though CPU is 35%.
    2. - Redo/Undo option in BaseCamp is a great option (almost infinite), but also CPU and Memory consuming.
    3. - When deleting a Trackpoint and BaseCamp is selecting multiple Trackpoints sometimes the wrong 99% of the track is deleted. This requires an Undo. As a result 10.000 points might be deleted and restored by UnDo within one minute.
    Suggestion: never delete 90% or more from a Track when selection multiple Trackpoints. This is most likely incorrect. I am deleting Glitches, not complete tracks!
    4. - Deleting Trackpoints is also a process in which a User might "hang" a process: continue to delete the next Trackpoint before the last deletion has been completed.
    This is stupid, monotonous and boring work, so I will do this in extreme tempo.

    Required for reproducing:
    1. - Having multiple List Folders en Lists.
    2. - Copy tracks for testing into one [Working List].
    3. - Start deleting Trackpoints.
    4. - Switch to another list (or preferably Library, Root Folder), Select a Track or Copy (Send to…) a Waypoint to [Working List].
    5. - Return to [Working List].
    6. - Continue deleting Trackpoints.
    Monitor Memory (Private Working Set): initially this was 200 Mb, after some time and repeating steps above: 400 Mb. (BaseCamp 4.3.5).
    In BaseCamp 4.4.1 these figures in Memory usage have doubled: 400 Mb to 800 Mb. (This is why I think the issue is harder to reproduce in BaseCamp 4.4.1 since more data is being handled in Memory.)

    So now my "conclusion" (best guess):
    1. - The issue will be reproduced after some time of working ánd after switching Lists (and Selecting or processing List Items). Switching List might also be: connect to GPS and Select Tracks in GPS.
    2. - The issue is not related to CPU usage.
    3. - The issue is related to Memory Usage. Perhaps a Reference or Memory Block or Object is sometimes (!) not being released correctly?
    4. - Is Undo/ReDo Cache referencing not only the current [Working List], but also some other List that was referenced before but should have been released?

    In BaseCamp 4.4.1 deleting one (!) Trackpoint might increase Memory usage by 500 Kb. After some time (and Memory usage is already being doubled) I don’t see any further increase in Memory usage.
  • Former Member
    0 Former Member
    We continuously are improving this area. The issue is that for every delete we rebuild the track list of point and recalculate all the stats. A lot of this has been redone already, but for larger tracks it is still slow. We will continue to improve this area but I hope that you have seen that we have made improvements already.
  • 0
    I have completely forgotten about this issue. Easy to forget since it has been resolved. Don't know in which version, but latest BaseCamp version is 100% ok.
    Thanks and compliments.
  • 0
    I have completely forgotten about this issue. Easy to forget since it has been resolved. Don't know in which version, but latest BaseCamp version is 100% ok.
    Thanks and compliments.

    Sorry nonsense.

    The issue still exists in Basecamp 4.5.0.
    But as before it is hard to reproduce. Not to be reproduced for one single day track.
    Only when returning from holiday, 20 tracks or more and sending tracks from archived folder to vacation folder. And only after some time, at least 15 minutes, of deleting track points.
    And as always, restarting Basecamp will resolve, until the issue has returned.

    Most irritating:
    Deleting glitches, mainly at beginning or end of track, will - often - delete the wrong (largest) selection of track segments. Leaving only the glitches at the beginning or end (which I intended to delete).
  • 0
    Yesterday another user found out splitting tracks also was suffering from degraded performance. Restarting Basecamp resolved.

    After further investigation he found out a VIRB was attached to an USB-port. Removing the VIRB seems to resolve the issue, permanently.

    Also reading my first post on this issue:
    If the GPS (Etrex 30) is not connected to PC/BaseCamp in Mass Storage mode there is no problem.
    If the GPS (Etrex 30) is connected to PC/BaseCamp in Mass Storage mode than the performance issue is reproduced.
    To resolve: Eject device, restart BaseCamp and performance in erasing trackpoints is ok!

    So my hypothesis now is:
    When using Basecamp you should not have any "storage" attached to any USB-port.

    I also found out (the hard way) you should not have a SD-card containing photos attached.
    My C-drive had a huge number of my photos cashed somewhere for Basecamp.

    My unverified conclusion, again, is the issue is resolved if you do not attach any "storage" (GPS, VIRB, SD-card) to any USB-port during Basecamp interaction.
    That is: not longer than required.