Hi @cdysthe,
I understand your sentiments and I do apologize for the trouble that led you to backup your backups. I am working closely with our engineers to address this particular issue as it’s indeed been plaguing many of you.
Hi @mia Thank you for looking into it. I spent hours yesterday removing and renaming the files that wouldn’t sync. I have gotten it all synced again now and it doesn’t seem to be halting after I removed the files and directories causing trouble. I also uploaded those directories using the Google Drive web interface.Seems to be files and directories with small files that have long names, and also files there’s many of in different directories like ~/.mediaartlocal which I had 400+ of in different directories. Still, InSync has to be stable regardless of file names, duplicates and size like other cloud sync applications like Dropbox and pCloud. pCloud is rock solid and never misses a beat, but I need Google Drive which makes InSync the only real option.
1 Like
@cdysthe Thank you so much for sharing what you did that led to getting things moving again.
I’ll raise this to our team so we can look into providing more dynamic stress tests that covers these types of sync loads and use cases.
I waited for this issue to happen again, installed the InSync package you sent us (which btw is an older version number than the current official version from the repositories, so not sure if the “fix” is meant to be included in the official releases already?) and… can confirm it’s still not fixed.
Hi @RobinJ1995 - the previous test build we shared is no longer considered as the fix for the rate limit errors since users have confirmed that the issue persisted. Thank you for reaching out and my apologies for misleading you on the Insync build! We are working on this once more in our current projects cycle and we will ensure to communicate with you and the rest of the affected users as soon as the new build is ready 
1 Like
Hi all! Could you please try out our latest build, 3.6.1? We have included an improvement for rate limit errors: New Insync version: 3.6.1
We’d love to hear how it goes for you!
This rate limiting issue really is giving you guys a hard time, isn’t it?
Can confirm it’s still not fixed in v3.6.1.50206
Hey @RobinJ1995 - it has, and we’re hoping to put it to rest as best as we can. Many thanks for letting us know about this.
Could you re-send your logs.db and out.txt files my way, via support@insynchq.com? Furthermore, could you try a couple of things:
- Upload another file (not included in that list) to the local folder (so that it gets pushed to the cloud)
- Upload a file via Google Drive web
And then let me know if either is successful?
I can confirm that other files upload/download fine, it’s just the files that it gets stuck in that stay in the list and don’t get processed.
Syncing did continue the next day, however. It’s still not good, but it’s better than the several days it usually took. Although I’m not sure if that’s due to a change on InSync’s side, or just coincidence.
1 Like
@RobinJ1995 I see! If you haven’t, could you send the logs to support@insynchq.com so we can check it out? Our engineer has a possible lead and the logs may help us confirm/debunk that!
We are also experiencing this issue and can see the rate limit exceeded in our logs.
Do you have an ftp site that I can use to upload the logs, as the file is too large to attach to an email?
Alternatively, is your engineer any closer to finding the problem?
1 Like
Hi @JPost!
We have some new leads to this issue and our team is investigating it further. Could you please upload the logs to your cloud account, then send a shared link to support@insynchq.com that we can download?
Please do include a link to this Forums post so we can trace it accordingly. Thank you!
We have noticed that an older version (1.5.7) is functioning properly, without this rate limit issue. The problem is the license we have cannot be used for this older version. Is there a way to use the current license for the older, functioning version until this issue can be resolved?
1 Like
Hi @JPost,
Could you send your account details and invoice to support@insynchq.com? I’ll check that out first and advise you from there. Thank you!
At this point I wish InSync were open-source so we could have a look ourselves.
Can confirm this is still happening in 3.7.0.50216…
I love this product but if such a fundamental issue is taking 6+ years to be resolved I’m afraid I have little hope.
Hey @RobinJ1995! Do you mind sending the latest logs.db and out.txt files to support@insynchq.com? Our engineer would like to isolate those reports to investigate it further (since we deployed improvements in 3.6.x).
Thank you so much!
I got this using the backup feature. I have a lot of development projects that contain .git folders and then i have a lot of web frameworks local to each project, so when i do a backup on those folders, its soo many little files. This is easier said then done but it would be better to see the backup feature do a snapshot-date-deltax.zip so it uploads zip files with one being a master zip and then ~/.local/insync/backupdb stores which zip files are needed to restore a file. This would fix rate limit exceeding on backups. For now im just going to go back to my duplicati for backups.
Hey @Scott!
Thank you for the insight and feedback! Do you mind sending your logs.db and out.txt files to support@insynchq.com with the link to this post? We’ll investigate the rate limit errors on your account, then see how your recommendation can be used in tackling this issue on backups (as well as other instances related to it).
Many thanks in advance!
I am also having rate limit exceeded issues. Syncs get clogged up with transfers stuck at 0 bytes making the software all but unusable.
!
Hi, @emerson!
Seems like we’re also in correspondence via email Thank you for reporting this and sending your log files our way