All files are downloaded again, with 130 files that takes long

Each time i run antfs-cli, all files on my garmin are downloaded. Is there an option that I should give to prevent this?
Or is it the this error: - Set time: FAILED

Kind regards, Meindert

meindert@i3:~$ antfs-cli
Driver available: [<class ant.base.driver.USB2Driver at 0x7f86604679a8>, <classant.base.driver.USB3Driver at 0x7f8660467a10>]

Using: ant.base.driver.USB3Driver
Request basic information...
Capabilities: array('B', [8, 8, 0, 186, 54, 0, 223])
Starting system...
Key done...
Searching...
Authenticating with Forerunner 310XT (3882674445)
Passkey: OK
Set time: FAILED
Downloading 130 file(s)
Downloading 2015-10-26_19-36-14_4_284.fit: [ ] ETA:[..............................] ETA: 0:00:00

Hi, I know that your issue is 3 years ago but have you solved? Same problem here.

What device is this? Is the file names identical (and content) identical each time?

I see the same (or similar) behavior with my Forerunner 310XT: once in a while (pretty predictably after DST change as described in issue #165 , but at other times as well) it will download all activities from scratch. This takes a long time (over one hour).

All newly downloaded files carry the current date when this happens, but the file content is identical to an earlier downloaded file.

For example, I just started the download and it is downloading all 97 files from the device even though I added only a single activitiy; using the "sum" tool, I can see that e.g. the following two files have the same content (meaning an activity from July now has today's timestamp):

2018-07-23_12-20-19_4_443.fit
2019-01-05_05-30-32_4_709.fit

I created a perl script to delete the duplicate files, but the slow download time is quite annoying.

I have the same problem with a 910XT. All files are re-downloaded, they all have the same date (only different seconds). When I upload them to garmin connect, it recognise some as already existing activities.

The output had:

Pairing: OK

Set time: FAILED

Same happens to me today and there was the DST in between the last activity.

@henningspruth May you please share your script (or at least the idea of it) to me or the community?

Taking a look on the code, it compare the local and remote files to build a two list of files to download and upload:

antfs-cli/antfs_cli/program.py

Lines 230 to 246 in f80ebca

    
           # Calculate remote and local file diff 
        
           local_names = set(name for (name, filetype) in local_files) 
        
           remote_names = set(name for (name, fil) in remote_files) 
        
           downloading = [ 
        
               fil 
        
               for name, fil in remote_files 
        
               if name not in local_names or not fil.is_archived() 
        
           ] 
        
           uploading = [ 
        
               (name, filetype) 
        
               for name, filetype in local_files 
        
               if name not in remote_names 
        
           ] 
        
           # Remove archived files from the list 
        
           if self._skip_archived: 
        
               downloading = [fil for fil in downloading if not fil.is_archived()]

At L236, a remote file is added to the download if it's not already know or not archived -- regardless of the skip-archived-mode.
In skip-archive-mode, at L245-246 all download candidates with archive bit set are kicked out.

@Tigge I guess the intention of L233-L337 is in first place to yield just the local missing ("new") remote files. And second also the ones that got modified for some other reason. This must rely on the fact, that the that state is reset if the file is successfully downloaded. Where is this done?

At https://github.com/Tigge/openant/blob/149d0a77165809de8f9232d2d7156020eb4f887b/ant/fs/file.py#L171-L172, is_archived is defined as the state some bit is set

    def is_archived(self):
        return self._flags & 0b00010000

and in L180-L187

    def get_flags_string(self):
        s = "r" if self.is_readable() else "-"
        s += "w" if self.is_writable() else "-"
        s += "e" if self.is_erasable() else "-"
        s += "A" if self.is_archived() else "-"
        s += "a" if self.is_append_only() else "-"
        s += "c" if self.is_encrypted() else "-"
        return s

a "flags-string" will contain A in this case. That's seems unusual to me; in good old DOS IMHO the archive bit is set if the file have been modified and to be backed up for this case and a backup program will reset this bit.

Is the meaning of this bit defined in the other way round in AntFS ? Or have this to be named is_not_archived or negated an some other code have to be changed. I may open an issue and send a pull request on the openant project if you like.

After some searching and studying other sources, I would say that I was wrong: In AntFS, the archive bit indeed have the sematic that a file is archived.

I will try to insert some debugging code to print the remote directory and the local and remote file lists.

@gjaekel, I moved on to a Forerunner 235, so I'm not using antfs-cli any more.

I used to run the attached primitive perl script in my $HOME/.config/antfs-cli//activities directory to identify duplicate files and then run "dupe.pl | xargs rm" to remove them. GitHub doesn't like .pl suffices on attachment so I added .txt.

dupe.pl.txt

@henningspruth Thank you.
@Tigge This script's idea is based on comparing MD5 hashes of the FIT files. I thought about hashing to compare local and remote files, too.

	# Calculate remote and local file diff
	local_names = set(name for (name, filetype) in local_files)
	remote_names = set(name for (name, fil) in remote_files)
	downloading = [
	fil
	for name, fil in remote_files
	if name not in local_names or not fil.is_archived()
	]
	uploading = [
	(name, filetype)
	for name, filetype in local_files
	if name not in remote_names
	]

	# Remove archived files from the list
	if self._skip_archived:
	downloading = [fil for fil in downloading if not fil.is_archived()]