#312 continued, cannot connect

[hboetes]

Although #312 is mostly fixed there are still a few bits left.

I still get getting address → cannot connect issues. Now all I have to retry and it's working again. But the auto-retry failed does not try it.

And this is whilst downloading a folder, where downloading all the other files from the same user works.

[mathiascode]

The connection issues are probably flukes that aren't caused by Nicotine+, but I'll check why auto-retry isn't working.

[mathiascode]

From what I can tell, there's code for the auto-retry feature, but it's never called...

[mathiascode]

Removed in e243758#diff-8c733c2cfa58a3e896747678fd3362c0, I'll see if I can reintroduce them.

[hboetes]

I did notice another situation today where the connection with a user was very flaky and the failed and retries took about 1 second. Per file about 100 log entries or so. A shame I didn't save the log output.

[hboetes]

@kiplingw
I just found the bug was still present. Could you please wait a bit more before closing bugs?
Thanks

[kiplingw]

Sorry about that @hboetes. The bug automatically closed when the PR was merged. Did you try running from Git? If you were trying the daily package from the PPA, it's probably not built yet. I will trigger a manual build now for you.

[hboetes]

@kiplingw
Thanks, I'm running straight from git via my own package manager: https://github.com/hboetes/cruxports_linux/blob/master/opt/nicotine/Pkgfile
and I updated about an hour after the commit. I just didn't run into the problem again. Now I did.

It only gets stuck after running into the cannot connect situation.

[hboetes]

Hmmm I just noticed there was another update and I now really have the new version. Sorry for the confusion. Please give me a few hours to test drive the new version. Thanks.

[mathiascode]

Oh no, this looks wrong on so many levels... :]

[hboetes]

Yeah, this need fixing. :-D
A manual retry does work though. The solution must be around the corner.

I also noticed files on 100% and still queued and in need of a retry. But that's another bug. A very small one.

And a file that's queued for about 10 minutes and after hitting retry it does start downloading.

[hboetes]

Sorry for all the drama. I made a thinko. Yes now it works. Yay! Thanks for giving me the opportunity to test this thoroughly.

[mathiascode]

There are still some small improvements that can be made to the transfer system. I ran into a problematic user that keeps closing the connection, which causes the retry spam seen above. I'll probably just remove that kind of auto-retry in favor of the timed one.

[mathiascode]

I wonder if Nicotine+ somehow gets confused about which downloads are finished or not. One download has downloaded fully, but is still in the temporary downloads folder, which is probably why the user keeps closing the connection.

[hboetes]

I wonder if Nicotine+ somehow gets confused about which downloads are finished or not. One download has downloaded fully, but is still in the temporary downloads folder, which is probably why the user keeps closing the connection.

The funny thing is that this problem does resolve itself eventually. Category unpredictable behaviour.

[mathiascode]

Can you test this branch? It should solve the issues with finished downloads getting stuck in the incomplete downloads folder. (just make sure you actually pull the branch changes)

git clone -b transferimprovements https://github.com/mathiascode/nicotine-plus

[mathiascode]

I made some small changes in that branch, pull the latest ones if you're already using the branch.

[mathiascode]

Pushed a few more fixes into the branch.

[hboetes]

Yes, much better! Thanks! I just downloaded a shipload of files, and they all arrived nicely, without the need of constant checking and retrying.