-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
All files are downloaded again, with 130 files that takes long #142
Comments
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 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:
|
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
@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,
and in L180-L187
a "flags-string" will contain Is the meaning of this bit defined in the other way round in AntFS ? Or have this to be named |
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. |
@henningspruth Thank you. |
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>]
Request basic information...
Capabilities: array('B', [8, 8, 0, 186, 54, 0, 223])
Starting system...
Key done...
Searching...
Authenticating with Forerunner 310XT (3882674445)
Downloading 130 file(s)
Downloading 2015-10-26_19-36-14_4_284.fit: [ ] ETA:[..............................] ETA: 0:00:00
The text was updated successfully, but these errors were encountered: