Does the XT autodelete archived tracks?

[BigBird]

@jfheath I was not aware of the shadow copy in the .System folder. I have not fiddled in there before. Checking there just now, I have Drivelog 16-29, weirdly missing 17. I'm sad to not find 1 - 9 there with a smug look on their kisser.

My example confuses me, too. As I've said, there may be a human in the loop explanation for some (10-15) but I'm suspicious that I'm to blame for 1-9. Next time I'm out with XT friends, I shall ask to take a peak.

On resets, I had to reset my zumo 396 a few times. My saved archives show the numbers not resetting back to 1, but rather incrementing onward across the reset. My guess is they were hard resets, but maybe there are flavors of hard, or maybe I'm wrong again.

On file size, yes, mine tend to be just over 1MB, too. Though the range is pretty wide. At the moment its 688kB (#14) to 2382kB (#18). Perhaps the same quirky algorithm that randomly messes with track segment length does double duty with track archive dumps.

Your Current.gpx will be bigger, because it includes not just the tracks that go over to the archive when the tracklog needs space, but also waypoints (favorites, saved, whatever you call them) and routes.

[jfheath]

All will become clear in time !!

What I understand at present is that

temp.gpx contains the data that has been transferred from Basecamp in the last usb connected session.
Current.gpx contains the tracks, routes and waypoints that have been imported to the XT after transfer

CurrentTrackLog.gox contains the activelog / TravelHistiry gpx files currently in use that eventually gets archived - the files that we are talking about.

I believe it was called something else on previous models, but cannot remember what it was at the moment !

Interesting that you have large archive files. I wonder when that behaviour started.

[BigBird]

Current.gpx for a LONG time has been a dump of what's in device memory. It is the net of all imports, on device edits & deletes, etc. Not the last transfer, like Temp.gpx

The device spits it out but never reads from it. If you delete it, next power off the device will spit out a new one.

[jfheath]

Yes- thats a better way of describing it. Items have to be imported before they will appear in Current.gpx.
And temp.gpx gets over-written when more transfers are sent to the XT if the USB link has been disconnected in the meantime.

You can get rid of Current.gpx if you delete Trips in trip planner, Favourites in Where to->Favourites, Tracks and (possibly) History using the XT screen. Then connect it to the computer and delete Current.

The missing gpx file is odd. I have seen it. (You know what I mean - I have noticed that one is missing) The drivelog also has the missing item - but it is handy to know it is there if you think you might have deleted one accidentally.

[BigBird]

Just to further flatten the cat, I was very hopeful I'd find 10-15 or even 1-9 under .System, but it seems whatever made them vanish (me or the system) outside .System was mirrored inside. Stand-alone weirdness that Drivelog17.gpx was NOT there but Archive/17.gpx still lives; that was definitely not me. I shall watch in the near future to see what disappears, when.

Pardon me belaboring this point, but there is no need to EVER delete Current.gpx on the device. The system never reads it, and the current system information will always overwrite the "old" Current.gpx so that it will current upon shut down. What you to do the Current.gpx file never matters to the GPS or to the accuracy of what you're pulling, provided you shut down the device before you connect it to your computer.

The CurrentTrackLog.gpx file is new to me since the last time I did a deep dive on these things. For thoroughness of understanding, it would require spelunking in the records to see when tracks are wiped from the current tracklog in active device memory and when they appear in the numbered archives, their .System cousins, Current.gpx, and CurrentTrackLog.gpx. Perhaps another time!

My two GPS geek projects that I will take on before that are:
1) fiddling with OSM for an upcoming Europe adventure (I'm in the USA)
2) experimenting with the detailed behaviors around shaping points when via points are skipped or navigation is started mid-route, whether on or off the route. I had a hiccup in recent routing due to a misunderstanding (or change?) there.

Track on!!!!

[BigBird]

Hopping in to flog a dead horse, since I was just in my device and looking at things.

Current.gpx used to have tracks in it in older devices (years back). Now, it does not. Apparently because those have been moved to CurrentTrackLog.gpx.

I am still confident Current.gpx behaves as it has for a long time, as I described earlier. And pretty confident CurrentTrackLog.gpx does the same, just for tracks.

@jfheath's description of temp.gpx is on point with my dated understanding, too.

Checking just now, the oldest track in CurrentTrackLog.gpx is immediately after the most recent track in the last Archive/29.gpx. There is no overlap between the two.

[jfheath]

I don't disagree about Current -

I should have said that Current.gpx contains the tracks, routes and waypoints that have EVER been imported to the XT after transfer

Temp used to be the same - on the 590/5 transfers were added to it cumulatively. Now on the XT it gets over-written with each transfer using a new conenction of the USB cable.

And there should be no overlap between CurrentTrackLog.gpx and the newest archived file (eg 123.gpx). It is moved over, given a new name (number) and a brand new CurrentTrackLog is created. I suspect that it does this when waking up or powering up, but don't know this for sure. It certainly doesn't make sense to do it when recording a track.

[BigBird]

I'm revisiting the details here since I'm fiddling with track histories again.

Cruising through Garmin support I found this item which states the same "last 20" track archive approach @jfheath et al provided. https://support.garmin.com/en-CA/?faq=1 ... tab=topics

Of late, I have seen the behavior on the device in practice align with that theory. I mentioned earlier that I witnessed exceptions to that rule (and maybe was to blame for some of them) but it has been toeing the line for a while.

I have NOT found a way ON THE DEVICE to save a track archive to the SD card before it gets deleted. You can share to DC card the history in the current track log, but not after it is written to archive. Bummer. So it seems necessary to connect up to a computer and pull the archive files at least every 200,000 track points if you don't want a gap.

That coding decision by Garmin seems arbitrary and capricious. But oh well. It is what it is. And it seems the earlier replies were far more on point than I gave credit.

I pinged Garmin support just now, mainly hoping for a save to SD card option. If I find out anything useful, I will update here.

[jfheath]

Tha'ts interesting - thankyou for updating this thread @BigBird.

When I was looking for information about the XT, I couldn't find anything specific like that. All I found was some reference to trips recorded over a certain time period. 20 archive files was the value that was used in previous Zumos that I have owned. I did not know that it was a new file every 10,000 recorded points.

Except - it isn't. It says 'Beyond 10,000' points it begins the process of transferring the older tracks to archive files. My CurrentTrackLog.gpx file has over 14,000 track points in it. This covers 3 days with reasonbaly long rides. A total of about 500 miles.
My newest archive file - 7.gpx - has only about 7000 points in it.

Most files are just over 1000K in size.
Looking at the logs, each line is typically 256 characters long some are 255. Some where the bike isn't moving are shorter.
But that is 4 lines per 1K of file size - approximately.
So 1000K is about 4000 track points - approximately.

Just checked with file 3.gpx which is 1,042Kbytes - It has 4,216 track points. Most of my other archive files are just over 1000Kb in size.

If you read the info on that Garmin link again, you can see that the wording isn't very precise:

An automotive device can store 10,000 point before it begins the process of archiving.
That doesn't exclude it starting before 10,000 or after 10,000 has been reached.

Up to 20 archive files can be stored. I believe that may be the maximum. It always was with the 590.

That means that the device can store over 200,000 points of data.

My files seem to indicate that it may be 3 or 4 times that amount.

Assuming it stores a track point every second, 200,000 points (which might be a minimum) is 55 hours of riding.

My data is limited. Although I have had a Zumo XT for 3 years now, One dies, and another was replaced in order to eliminate a possible reason for the repeated U turn problem. And there was Covid in the middle of that. So I have never had my archives reach double figures yet.

However - a quick analysis of one 3.gpx shows that the average time betwen the 4216 track points - excluding long stops was 7.4 seconds.
This will vary according to the type of roads being ridden.

So if each file can contain 4000 points, with 7 seconds between points, that is 560,000 seconds of riding. 155 hours.

Enough for a long European trip, I think.

But this is only me pratting around with some figures at the other extreme. I suspect Garmins figures err on the side of caution. Mine are probably too optimistic - based on just 7 files of riding archives.

I cannot explain why my 7.gpx file was only 80% of the size of the other log files. One thing is for sure though - the currenttracklog.gpx can get to be quite a size before it offloads to the archive. The 590 never used to do this - but the 590 used to spread a day's trip over the joint between two archives. According to garmin, that doesn't happen any more. I have seen the CurrentTrackLog grow to more than 3Mb on my current Zumo.

[lkraus]

I think a track log is also closed every time the GPS loses power and sleeps or is shut down. Food and gas stops, stops to sight see, adjust gear, check the map because you don't trust the routing, etc. can all quickly use up the 20 track capacity, even if the distance between stops is short.

...
I have NOT found a way ON THE DEVICE to save a track archive to the SD card before it gets deleted. You can share to DC card the history in the current track log, but not after it is written to archive. Bummer. So it seems necessary to connect up to a computer and pull the archive files at least every 200,000 track points if you don't want a gap.

I can't think of anything that the XT will save to the SD card. But you can save the tracks to internal memory and they will not be auto-deleted.

The Tracks app starts with the Saved Tracks tab open. Tap the other tab (calendar-ish looking icon) to see Unsaved Tracks, which are the tracks generated by Travel History (aka Active Logs in BC).

Select All Unsaved, or an individual track, then the wrench icon to Save Track. Provide a name and it will then be available in Saved Tracks, and will not be auto-deleted.