You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What I saw:
Almost every attempt to download a file from a Forerunner 610 with v 3.00 firmware on a PC running Ubuntu 18.04 fails for me with a python traceback. There appear to be multiple different exceptions which are not caught by the antfs-cli script.
Occasionally the script will be caught in a loop repeating the message: (110, u'Operation timed out') (ant.py:185). When this happens the script must be killed from another terminal to regain control. Control C did not work.
Today there were 58 log files generated while only 2 out of the 5 tracks on the watch were downloaded.
In total I have 946 log files for about 15 tracks successfully uploaded.
There have also been a few files created that do not relate to any tracks on the watch. Most of these are null files.
Sometimes the script would exit with Passkey: FAILED. The bash wrapper below would exit when this happened.
What I expected to see:
The tracks should have all been downloaded from the watch and transferred to the Garmin web site.
There should be no python tracebacks when the script exits.
The script should exit with appropriate exit codes so that antfs-cli can be used in a shell script.
Subsequent script runs should not fail or download anything unless there are new tracks on the watch.
How to reproduce:
Make sure that Ubuntu 18.04 has all its packages updated.
Make sure both python 2.7 and 3.6 are installed.
Install antfs-cli, pyusb, openant, and garmin-uploader from their respective git repositories using a git pull on 2019-01-26.
Copy the file scripts/40-upload_to_garmin_connect.py into the directory ~/.config/antfs-cli/scripts and make sure it is executable.
Set up the .guploadrc file.
Run sequential attempts to transfer tracks using the bash shell script:
date +%Y%m%d-%H%M%S
printf '\n'
until antfs-cli --upload --skip-archived
do
printf '\n\ntrying again in '
for count in {9..1}
do
printf '\b\b%2d' $count
sleep 1
done
printf '\b\b 0\n\n\n'
date +%Y%m%d-%H%M%S
printf '\n'
done
Additional comments:
Obviously this is not happening to other people. I would like to find out what is so very different with my system that is causing all the problems. For example, should I use sudo pip install instead of git pull; sudo python setup.py install? Is there a problem caused by the two different versions of python installed?
I first tried to use antfs-cli in 2017 to avoid using a Windows VM. The tool downloaded about 5 tracks on the first attempt, and then failed every other attempt to download new tracks. I gave up on antfs-cli until the recent upgrade to Garmin Express 6.11.1.0 broke Windows uploads. Reverting to 6.10.0.0 did not fix the problem (other people have reported the same thing). To work around this, I re-installed antfs-cli and its dependencies, and found that again antfs-cli downloaded about 5 tracks on the first attempt, and then almost never again worked.
Which log files would you like me to upload?
Note: The various static messages that are printed to stdout should also be sent to the log file so that users can grep in the log files for conditions that are printed to the terminal.
The text was updated successfully, but these errors were encountered:
What I saw:
Almost every attempt to download a file from a Forerunner 610 with v 3.00 firmware on a PC running Ubuntu 18.04 fails for me with a python traceback. There appear to be multiple different exceptions which are not caught by the antfs-cli script.
Occasionally the script will be caught in a loop repeating the message:
(110, u'Operation timed out') (ant.py:185)
. When this happens the script must be killed from another terminal to regain control. Control C did not work.Today there were 58 log files generated while only 2 out of the 5 tracks on the watch were downloaded.
In total I have 946 log files for about 15 tracks successfully uploaded.
There have also been a few files created that do not relate to any tracks on the watch. Most of these are null files.
Sometimes the script would exit with
Passkey: FAILED
. The bash wrapper below would exit when this happened.What I expected to see:
How to reproduce:
Additional comments:
Obviously this is not happening to other people. I would like to find out what is so very different with my system that is causing all the problems. For example, should I use
sudo pip install
instead ofgit pull; sudo python setup.py install
? Is there a problem caused by the two different versions of python installed?I first tried to use antfs-cli in 2017 to avoid using a Windows VM. The tool downloaded about 5 tracks on the first attempt, and then failed every other attempt to download new tracks. I gave up on antfs-cli until the recent upgrade to Garmin Express 6.11.1.0 broke Windows uploads. Reverting to 6.10.0.0 did not fix the problem (other people have reported the same thing). To work around this, I re-installed antfs-cli and its dependencies, and found that again antfs-cli downloaded about 5 tracks on the first attempt, and then almost never again worked.
Which log files would you like me to upload?
Note: The various static messages that are printed to stdout should also be sent to the log file so that users can grep in the log files for conditions that are printed to the terminal.
The text was updated successfully, but these errors were encountered: