Thanks for the message, Katherine. To add a data point, I have 12 projects in my Dropbox folder. My smallest 4.5 MB (template), my biggest 10.27 GB and a total space taken by the 12 projects of 20.24 GB.
The issue I was having seems to be solved. I logged into the Apple ID we shared, deleted the app, and the downloaded it and synced. It seems to be working. I do have auto sync off. I have not typed anything or synced anything, so I don’t know if it’ll shut down on that yet. I’m leaving with this small moral victory over technology from a not so tech savvy person 
Does reducing the number of projects help?
Katherine
I haven’t tried troubleshooting and testing, so I can’t answer on that yet.
I had previously moved all my projects to a new folder, then moved them back one by one. One project caused the crash problem, so I moved it back out and continued moving my other projects. I was able to sync all my projects except the one “problem” project, so I assumed the problem lay with that project. Unfortunately, that project is my main WIP.
After reading this, I created a new folder and set up Scrivener to use it as the sync folder, but this time I moved the “problem” project first, and it synced. I then continued moving other projects and eventually, Scrivener started to crash again.
So I now have two Dropbox folders, one for active projects and one for inactive projects. Scrivener is only syncing the active projects and I can use it to work on my main WIP again.
Not ideal because I can’t access the inactive projects from my iPad right now, but it’s not as big of a showstopper as before.
It sounds to me as though it is not known that your device is capable of storing thousands of projects without syncing them (those of us that don’t use Dropbox at all would have a fun time using Scrivener otherwise!). Think of the sync area more along the lines of being strictly a transfer mechanism. It’s where you put the stuff that actively changes on a regular basis from multiple contexts, with the idea toward making it more convenient to keep these contexts in parity. In the old days, this would be your floppy disk you use to carry changes around, not the hard drive where you do your actual work.
Most folks will not require archives of projects that never change to be stored in an area that is designed entirely around using the Internet to aggressively monitor and modify each device for changes. It would be like keeping all of your store’s inventory in the truck you use to pick up the morning doughnuts for the staff. The sync code is having to trawl through likely tens of thousands of folders and files, all to work with a small dozen or so that change from one day to the next. Even aside from the actual bug itself that is causing crashing, if one can reduce their sync times from minutes to seconds, why not?
Instead, drag old projects below the Dropbox bar in the project management list, and now they are “offline”, but readily accessible. If for some reason in the course of working through something, you find one of these older projects requires an important revision, it is an extremely simple matter of dragging it back above the Dropbox line to push those edits to all devices. You could at that point then store them “offline” on those devices if that’s the end of it, or leave it active for a while. Why not—it’s not a big deal at this point, since the sync folder is not overloaded at all times—a little extra probably won’t push things over the edge.
It’s not going to work for everyone, some people really do need everything synced, but I think most people out there only work in one or two projects at once. So for them, this isn’t really a “solution” to the actual bug, obviously, it’s more along the lines of general advice—but it becomes relevant to this thread when one gets the feeling that we’re saying you should do without having access to your work!
I’m having a very bad day, so maybe I’m just misinterpreting your post. In fact, I deleted my first reply because it was pretty scathing, which may be other (unrelated) issues from today clouding my judgment. Let me just say this:
You seem to be saying that the way I’m using Dropbox and Scrivener is wrong, that I should only have current projects in the folder Scrivener for iOS is using. That goes against the whole point of storing your projects in the cloud: to access them any time from anywhere. It’s not unusual that I need to refer back to an “inactive” project for one reason or another. To suggest that people move all but their current projects out of the Dropbox folder Scrivener for iOS uses because the cloud is like a “floppy disk” is both condescending and ignorant of how some people need to work.
More to the point, it works in older versions of iOS and is broken for some in iOS 13 and needs to be fixed.
There is nothing condescending and ignorant about the suggestion.
Having only active projects in the synch folder is effective, and certainly one of the work arounds while they address the issue.
No one is saying don’t store your inactive projects on Dropbox, just stick them in another folder thats not synched. Easy enough to move to the synch folder if you reactivate an old project.
In all this discussion of workarounds, it should be worth noting we are soon in the year 2020 and sync problems like this belong in the year 2010. I do get that the Scrivener file format is complex, tracks many different things which make sync a little more complicated, but I hope the devs are getting that this cannot go on in the years to come. These days, transparent sync is not a major feature, it has simply become the baseline of expectations (especially when it works transparently with the main competition). Having it break unexplainably, with still no official solution in sight (this forum thread has gone for over a month) is really worrying.
It isn’t clear to me if the fundamental advantage of what I am describing is being communicated well enough, if that’s your idea. If you return to the project screen on your device and tap the Edit button, scroll to the bottom of your project list, and you will find a presumably empty section, headed by the phrase “On my iPad” or something to that effect. If you drag a project from Dropbox into that area then it is effectively offline. But note that when you tap back out of edit mode you can fully access this project. You can even edit it and later send it to another device. There is no functional difference between the projects in these two lists, save that one doesn’t clog up the sync mechanism.
As I understand it, you already have these projects stored in a different folder on your Mac, so they are available to it while you are there—the idea is to make them available to your iPad as well.
The way I would go about it is using iTunes or a better file manager to copy the contents of that folder into Scrivener’s document area with file sharing. Then you don’t have to waste the amount of time it takes to download them over the Internet. They should show up on your device the next time you view the project management screen.
The design intent of the software is to store only those projects you are actively working on in your sync folder—this isn’t a matter of opinion. The kind of sync we use is a heavy-duty process, necessitated by the types of tools we have available to us, and not at all like your iCloud Drive attachment in Files, or even the Dropbox.app itself. Those things have the luxury of keeping 99% of your stuff online and off your device. They also have the luxury of controlling both ends of the process, and thus being able to optimise how their server works with their client. We don’t have either luxury, and on account of how the Dropbox tools work, we must compile a full manifest of every single file and folder (which can be tens of thousands), each and every single time you press the sync button. It’s not ideal, but it’s the sort of technology that is available to this type of large-scale program.
So bearing those two facts in mind, it stands to reason that the more “dead weight” you store in this folder, the slower sync will be, and the more likely it will be that you run into technical limitations of all sorts, including outright failures when the context is suddenly dramatically changed around the stressed design limits.
Yup, I’d say it’s good practice in general as it will keep sync snappy, but until the bug is fixed, it’s a bit more along the lines of a necessary approach.
Unfortunately it won’t work for everyone—someone posted that the one WIP is too big all by itself to safely sync, but hopefully it helps some.
We are aware of the issue with iOS 13.
I don’t think it’s helpful to assign a moral judgment, that a particular way of using Dropbox is “right” or “wrong.” Rather, the intent is simply to note that some approaches are less likely to encounter the issue than others, for technical reasons that will continue to be true even after the immediate issue is resolved. Perhaps better terminology would be that some approaches are more (or less) reliable than others.
Since your ultimate goal is to get work done, it would seem to me that the more reliable approach might be preferable, even if it is not the Platonic Ideal that you would like to achieve.
Katherine
Potentially relevant:
zdnet.com/article/ios-13-ha … -and-ipad/
“The fact that Apple hasn’t spotted and fixed this glaring problem hints that the company doesn’t take the needs of heavy, high-end and professional users seriously, and as such, it is becoming hard to recommend the platform to professionals looking to do real work with it.”
Katherine
I wouldn’t expect much different from ZDnet.
Seriously though it is an absolute pain in the proverbial, yet let’s be realistic.
It can take time to nail down precise cause and the fix and test to ensure the fix doesn’t introduce more issues. The Win development team would be able to confirm that and then some I suspect.
I can confirm this is false.
When troubleshooting my projects I cleared my Dropbox, downloaded the app, fresh and moved only 1 project in that was failing before (found by syncing 1 by 1 until error) and it failed.
1 project fails (if I only include that one known failing project)
I have 2 that fail which happen to be my largest ones which led me to incorrectly believe it had something to do with project size.
- also, my largest project is a lot smaller than a lot of others mentioned on here, to my surprise!
My only conclusion now is that it must have something to do with project makeup.
Perhaps projects started in scrivener 2 and moved to scrivener 3, or projects with a lot of snapshots or imported icons or multiple folders under the main project or using 1.2 spacing or something…
Something in two of my projects fails the sync while all the others are syncing just fine and even syncing faster than Scrivener used to…
So what’s the deal with those specific projects that breaks in ios13 and Scrivener?
If anyone can provide a sample project that singularly crashes sync, we’d certainly appreciate it. Zip it up and send it to our support address. If it’s over 10mb, a file sharing option will be necessary (since the project is presumably on Dropbox you can probably share it in situ).
I’ve had this problem for a while. I’ve skimmed a lot of this thread but I was wondering if somebody could just give me the TL;DR?
What is the current best workaround?
I’m using an iPad pro 2018. Latest software everywhere. Really need to get these projects back to the cloud so I can edit them on desktop.
Thanks.
You could always use the Share function from the IOS Scriv projects screen to email the project over to your desktop.
Perfect. Thank you for this suggestion. Good temporary workaround.
“One of the biggest issues in iOS 13.2 is RAM management problem that is causing applications to be killed when running in the background. Early tests indicate that iOS 13.3 does solve this problem, at least to a certain degree.”
Apple releasing first public beta of iOS 13.3 today - 9to5Mac :https://www.google.de/amp/s/9to5mac.com/2019/11/06/apple-releasing-first-public-beta-of-ios-13-3-today/amp/
Maybe this will help us?