Erase trackpoints from historical Track in BaseCamp 4.3.4 too slow

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.

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.

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.

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.

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.

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.

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).