Hi @kyle,
Can you send your logs to support@insynchq.com so we can check why it didn’t auto-update? Were you, at any point, able to see “version 3.0.27 is available now” on the bottom of your UI?
Hi @kyle,
Can you send your logs to support@insynchq.com so we can check why it didn’t auto-update? Were you, at any point, able to see “version 3.0.27 is available now” on the bottom of your UI?
I’ve got the same issue. After updating to 3.0.27 (by downloading and running the installer), the files are still stuck.
edit: I resolved it by moving the stuck files to another subfolder. They were immediately uploaded from the new location, but the original versions (which weren’t really there anymore) were still shown as stuck in the sync list. After restarting Insync everything was fine.
Apologies for the thread jacking everyone. I’ve started a new thread regarding the update issue.
I’ll add that I’ve not experienced any of the sticking issues described here on Windows 10 pro 1903 with all versions of insync v3 to date. It would help if y’all could include any additional information about your systems.
edit: similar issue: File stuck uploading at 0 bytes
I’m having this issue too, I manually updated to 3.0.27.40677 to try and fix it, but I still have 12 files sitting at “Uploading 0 bytes …”.
Pausing/Resuming doesn’t seem to fix it.
I will email my logs, referencing a link to this post momentarily (Edit: Sent!)
Same, got stuck with version 3.0.25
I am on Arch and unfortunately decided to upgrade to Insync 3.0.27 from my perfectly working older 1.x.x insync. Should have left well enough alone instead of upgrading.
Insync 3.0.27 gets stuck at syncing (uploading specifically) within a few seconds (after uploading about 9 files).
I noticed that this seems to be a recurring complaint. Any updates on when we can expect it fixed?
Alternatively, is there any safe way to downgrade?
EDIT: It is now stuck as soon as it starts up. Shows “Uploading 0 bytes…” and the cpu usage is like 100%
Hi @Sanjiv_Erat,
If you’re on your Feed tab, can you switch to Attention Required and let me know if the CPU still sits at 100%?
Our engineers are prioritising the stuck syncing issues reported and we’ll be updating all affected users as soon as it’s been fixed. Can you send your log files to support@insynchq.com with the link to this post?
It was stuck at 100 and was barely responsive. Anyway, I downgraded to 1.5.7 and things have stabilized (hopefully!). For those on Arch, the AUR is https://aur.archlinux.org/packages/insync1
I’ll hold off on upgrading till 3.x.x is more stable.
Hey miamoran. This post is 5 weeks since original posting about file sync get stuck - and there are many other posts just like it for version 3.025 and 3.027 (including mine). Can you please update us on the status of 'our engineers are prioritising the stuck syncing issues" and a possible fix release? Inquiring minds (and buyers) want to know.
I’m on 3.027 and Ubuntu 19.04. Having the same issue (files getting stuck). It seems to happen randomly, sometimes a program restart helps.
However, it is really annoying that I now have to check the sync process frequently to make sure files are actually synced. Do you have updates on the issue or an ETA when we could expect a new release?
Wow, I wish I would have found this thread before I bought a license!
Same problem here, I’m using 3.0.29 on Mint 19.3.
For me this problem didn’t pop up until I added a Google Drive local sync of a very large project folder (12GB, thousands of tiny files).
I’ll see if I can track down this older version that others like so much.
Hi @jasontwinters,
Could you send your log files to support@insynchq.com with the link to this post?
Please include the following:
If they’re too big, you may send a link for me to download.
If you wish to revert to 1.5.7, the builds can be found here.
OK. Something weird I just noticed. I have this issue on archlinux (home PC). But it seems to work correctly on my PC at work, which runs manjaro. I am trying to figure out what could be the cause of this, but so far I have no idea…
I’m on 3.0.31 Win10 and have the same issue. It also started for me after trying to sync a large folder (~150mb) containing lots of small files and subdirectories. Glad I decided to get a trial first.
Same here, with Windows 10 and 3.0.31. This is so frustrating.
After analyzing the log file logs.db
with sqlitebrowser, I found the items which are getting stuck are raising the following error:
Traceback (most recent call last):
File "idesksync/workbase.py", line 247, in __run
File "idesksync/syncwork.py", line 1573, in _do
File "ideskgd/gdcloud.py", line 79, in add_dir
File "ideskgd/gdclient.py", line 654, in insert_folder
File "ideskgd/gdclient.py", line 662, in insert_file
File "ideskgd/gdclient.py", line 279, in request_resource
File "idesksync/cloudclient.py", line 170, in _request
ideskgd.gderrs.GDUserRateLimitExceeded: 403: userRateLimitExceeded: User rate limit exceeded.
It seems that I hit a limit on the Insync GDrive API. Not sure if the limit is related to my account or the Insync corp account. It would be nice to be able to increase the quota in either case.
Can someone confirm they have the same error?
I have the same problem on the newest version of Ubuntu and Insync, very frustrating.
On Windows10 3.1.8.40816 mine stalled this morning too. I also cant get the GUI to open.
This is in out.txt:
C:\Users-------\AppData\Roaming\Insync\App\ideskui\appui.py:495: RuntimeWarning: coroutine ‘APIFunction.call’ was never awaited
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
MemoryError
C:\Users-------\AppData\Roaming\Insync\App\ideskui\appui.py:498: RuntimeWarning: coroutine ‘APIFunction.call’ was never awaited
RuntimeWarning: Enable tracemalloc to get the object allocation traceback