Hi all,
I have tried 3 times now to upload about 2 gigs worth of files using the cloud file browser but keep getting the below error. There are no known server issues, and no errors in the server side logs that I can see. These are wav files between 1 to 200 megs, and I have about 1,000 of them I select to upload at once.
Here’s the end of the logs from the client side:
[07/13/17 15:58:00] http-tx-mgr.c(748): libcurl failed to GET https://cloud.server.com/seafhttp/repo/5d7ec39c-d98f-46c3-ba09-6149ed56c86d/commit/HEAD: Couldn’t connect to server.
[07/13/17 15:58:00] sync-mgr.c(764): Repo ‘My Library’ sync state transition from initializing to ‘error’: ‘Failed to get sync info from server.’.
[07/13/17 15:58:30] http-tx-mgr.c(748): libcurl failed to GET https://cloud.server.com/seafhttp/repo/5d7ec39c-d98f-46c3-ba09-6149ed56c86d/commit/HEAD: Couldn’t connect to server.
[07/13/17 15:58:30] sync-mgr.c(764): Repo ‘My Library’ sync state transition from initializing to ‘error’: ‘Failed to get sync info from server.’.
[07/13/17 15:59:02] http-tx-mgr.c(748): libcurl failed to GET https://cloud.server.com/seafhttp/repo/5d7ec39c-d98f-46c3-ba09-6149ed56c86d/commit/HEAD: Couldn’t connect to server.
[07/13/17 15:59:02] sync-mgr.c(764): Repo ‘My Library’ sync state transition from initializing to ‘error’: ‘Failed to get sync info from server.’.
Is this a known issue, that the cloud file browser can’t handle a lot of uploads at once? I was trying to use it to avoid needing to sync the whole library down just to upload stuff to it.
Thanks for the help!
Since it works like the upload through a browser yes, it’s not made for your requirement. I recommend to upload it directly with the client. You can create and upload it to an empty library and copy it later via webinterface to your main library if needed.
Thank you! Good work around, I am syncing with the client now to a temporary library.
You may be on to something here, as when I take a closer look at the logs, both the cloud file browser and the android client use POST to seafhttp/upload-api in order to upload their files.
I am experiencing the same frustration with the android client in my other forum post that has me pushing the developers sort of hard to get this resolved - unexplained upload failures when there’s a large amount of files queued up in the upload queue.
I bet an underlying weakness with the way the upload api works that both the cloud file browser and android app utilize is the cause of these issues.
@daniel.pan Thoughts?
So another point of data on this issue, I just tried it again and it died at exactly the same amount uploaded - 615.7 MB.
This number does not seem “suspicious” to me in the sense that it doesn’t look like a default number that would be configured in a service somewhere.
I am super confused right now…
This looks like a timeout or something.
Please have a look at this settings:
[fileserver]
#Set uploading time limit to 3600s
web_token_expire_time=3600
# Set maximum upload file size to 200M.
max_upload_size=200
# Set maximum download directory size to 200M.
max_download_dir_size=200
More here: https://manual.seafile.com/config/seafile-conf.html
Of course you have to increase these limits and restart seafile server. Which webserver do you use? How is it configured?
Yes, good call! I found the web_token_expire_time setting last night and changed it to be 24 hours then set my test machine up to begin uploading the files over cloud file browser again. This fixed it, no more connection closed errors! I wonder why the cloud file browser doesn’t get a new token for each new file it uploads…?
What I am most surprised about though is so far this does not seem to have fixed the android upload problems. I would have expected it to since the app and cloud file browser seem to upload files in exactly the same manner. Need to continue testing some more.
Yeah the Android app is still exhibiting the same behavior, getting some files uploaded then saying the upload was canceled.
Frustrating! 