-
Notifications
You must be signed in to change notification settings - Fork 134
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
Forcibly re-queue uploads that stop due to an error such as "Can't connect" #1563
Comments
This is implemented for downloads, but not uploads yet. |
It does for a single file, but selecting multiple files that all have the "Can't connect" status doesn't work (in 3.2.0.dev1), which makes it necessary to wait until all transfers have finished then go through each one individually. On slow connections this is very tedious (even when multiple upload slots are available). Note that the Queue position of the stuck Uploads becomes duplicated in this scenario, which might be causing the inconsistent behaviour? Disconnecting+reconnecting doesn't resolve it, but restarting the application does, perhaps because all Queue position are then reset (perhaps "Can't connect" items need to be given a Null position in the Queue). |
This is fixed in 91049c3. |
This is cosmetic, but fixed in 7f12d70 |
With the recent improvements to the queue system, this should be doable if we simply change the status text back to "Queued" and let the queue system pick up the transfer eventually. If the user doesn't want the file anymore, they'll reject it as usual. |
I noticed someone grabbing some music from me whose upload was stopped due to "can't connect." When I click on them and hit Retry, it works just fine, so presumably the connection timed out or something. Can there be an option to automatically retry any uploads (and downloads if it isn't already a feature) so neither me nor the downloader have to hit Retry?
Thanks for your work.
The text was updated successfully, but these errors were encountered: