-
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
TransferFailedException #132
Comments
I have a similar issue with my 910-XT. I usually solve it by deleting ~/.config/antfs-cli (or rename it, note you have all your downloaded fit files here), then run again. Have to do this quite often. |
Thanks for the tip, Eothred. It looks like I can just delete the authfile (not the whole .config directory). That fixes the problem, temporarily. I am still getting the USB failed to close error so I still have to kill antfs-cli with Control-C. Is it possible that the authfile isn't getting closed properly when I do that, and is getting corrupted? I currently only have a good authfile. I'll make a copy and see if it is different next time it failes. |
That is a bit weird. I'll see if I can look into it a bit more in detail. There is now a --pair switch that can be used to force a re-pair. Perhaps that is a better workaround if it do work. |
Hi Tigge, Thanks for looking into it. What happens is usually that my GPS first show "transfer status", then after a while just quietly goes back to "default screen". antfs-cli is still staying in "transfer mode" for a while before it eventually seems to timeout or similar. The "--pair" functionality sounds like a useful workaround for now, I will try that next time! |
Hi Tigge, I tried the new --pair switch, and it did force a re-pair (I get the pop up on the watch saying "pair with antfs-cli?"), but the transfer fails almost immediately. If I go and delete the authfile, the transfer works the first time. I would love to help diagnose this, but don't really know how. Is there a way to check if the authfile is "valid" somehow? Or figure out if there's somewhere in the code involving reading the authfile that's causing this problem? Here's the error I'm currently getting:
|
Updated information: But that seems to be what makes things work. If I don't enable pairing on the watch, deleting the authfile by itself is NOT sufficient. It seems that I have to enable pairing on the watch AND delete the authfile. Sometimes that combination still results in a failure to connect (before the fit file starts transferring), but I can retry and it will connect and transfer the files. If I don't delete the authfile and enable pairing, the fit file transfer always fails. |
That error is in a new part of the code that I pushed yesterday, so it is probably not related to the other error you where getting. It is now trying to syncronize the time to the watch, but it is failing here for some reason. Do you have a log file I can look at? |
Thanks for the response! I just did a successful transfer (using the remove authfile and set the watch to pair trick) and it still said "set time: FAILED" but the file transfer succeeded. The output is here:
Is there a way to attach logfiles, or should I just paste it into a response here? The file is pretty large. |
I recommend using https://gist.github.com/ for log files. Either that or send me an email. It would be nice to have a log from a failing transfer as well as a good one if possible. |
I've tried the --pair twice now (sorry don't use my Garmin that often), worked very well. I'll try to remember to provide you the log files. Usually without the --pair option it fails 4 times out of 5, in particular for larger files. |
https://gist.github.com/Eothred/bf42a1948a6ffc2f985b both stdout and the log file (in case you see any useful info there as well) |
Sorry for the delay, here are my successful and unsuccessful log files. It seems that I have to enable pairing on the 910xt to get things to work. The --pair option does help, it means I don't have to delete the authfile directly. Successful transfer: https://gist.github.com/LeftyAce/1500b93fd62f2130cee5 |
Just to add info here, the --pair clearly solves the issue (though it is not the way you want to solve it I guess). I downloaded 23 workouts from the watch in one go without any errors with the pair option. Without that option I would typically have to try an average of 5 times per workout. Larger files would fail more often (my impression). |
I feel bad that I'm just posting symptoms and have no idea how to diagnose this. For me, --pair makes things more likely to work, but I still get failures; I have to retry about every third time, and I may have to retry multiple times to get it to work. It does seem to be a bigger issue for large files. Is there a timeout somewhere that could be causing a problem? Or is there a way to see if my system is doing something stupid like shutting off the ant+ stick? (I checked that in Powertop and did have to change some settings so the ant+ dongle wouldn't get powered off to save battery on my laptop...) |
I have the same problem with my 310XT, but I already had similar issues with the Garmin software for Windows, so I'm pretty confident that this is not a bug related to anfs-cli or the underlying stack but some flaw of the Forerunner device or the ANT stick. Or maybe it's interfering with some other radio communication device (although I've tried to exclude that). Because I first assumed that the problems might be related to Garmin's low-quality Windows software or drivers, I connected my ANT stick to my Raspberry Pi Model B+ running Raspbian. With Garmin's Windows software, I had to turn off and on the device to enforce a new try after each timeout (which made it practically impossible to sync after a while). Thanks to this great software, I was able to write a bash script that automatically repeats the sync until #!/bin/bash
until antfs-cli
do
echo "Trying again..."
done Maybe this workaround works for others as well. Maybe increasing some timeouts, like suggested in #145, would help as well. |
Hi all, and thanks for the great work on this project.
I'm having an issue downloading files from my watch. It worked fine for a few days, then it would fail mid-transfer, but if I retried a few times the transfer would complete, but now it fails every time. I'm running afdc5ff. I also get the libusb write failed, closing anyway hang at the very end (from issue 129). I got this even when transfers were working (I would just Control-C to quit).
Here is the command line output. Please let me know if there is more information I should provide.
The text was updated successfully, but these errors were encountered: