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.
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?
Apple just released 13.2.2 that should also fix the RAM issue. Not sure if this helps the Scrivener issue. I decided to now switch completely to my iCloud workaround and reconsider if there is a solution for Scrivener iOS, although I’ve been happy with my solution now.
I have just installed the update and unfortunately, it does not fix the issue. Scrivener is still not syncing my projects and is crashing (closing).
That would have been nice! But I didn’t have my fingers crossed when I read it only fixed things running in the background. We’re most definitely in the foreground when this happens. It does however make me slightly hopeful that they are aware of RAM issues in general, and this is only fixing the first half of the problem.
I don’t want to sound rude, but do we know for sure this is half of the problem? And do we already know where the other half of the problem lies?
No, I’m only speculating, hence hopeful in the sense that they’ve identified RAM issues under some conditions and that those conditions sound a lot like what we’re seeing evidence of (the system shutting Scrivener down for memory issues and generating a report).
Hey AmberV,
I submitted my 100% crashing project via Dropbox this morning. Hope you got it and hope it helps.
Thanks for the head’s up, I’ll check the queue.