Scrivener iOS syncing via Dropbox continues to crash the app

On my iPad Pro 9.7 inch with 256 GB, it works fine. On my iPhone Xs max, also with 256 gb, it doesn’t work even if i switch folders. It looks like its working, and then it doesn’t. I have decided simply not to use it on my iPhone until there is a fix. Not that crucial, although slightly annoying, that I give up on iPhone as long as my iPad continues to work.

Hi Thomas, thank you for your efforts. I’ve also been doing the whole copying through the Files app thing manually since it stopped working at the 3rd week of September. On one hand I think it’s really annoying that this has been going on now for a month and a half, on the other hand, it proves that the iCloud copying (it’s not the same as iCloud Sync) works reliably, quick and transparant. This was not the case in previous versions of iOS.
It makes me doubt about just doing that as my default and leaving Dropbox for what it is. BTW, my projects sometimes go to 1-10GB (10GB is the biggest one) and they all have been uploading quickly and reliably. Both from an iPhone 8 Plus and an iPad Pro 11", and a 2015 iMac.

What I wanted to ask is: you put on a command and it started copying a project. How did it know which project to copy? It just took the most recent one? I don’t think your shortcut is a good option, because my projects are now not all together in a Scrivener folder anymore on my iCloud Drive, which would make it more difficult to make an automated shortcut, but I’m curious. Thanks again!

Hi,
Well, the shortcut is not picking a project file by itself, it is user controlled. In other words, I select the project from the dialog and then the shortcut copies it into the Scrivener iPad directory. So it is not fully automated but just supposed to make the copy hassle a bit easier.
Greetings,
Thomas

I would here share an observation about this important bug.
Since the failure and in waiting for the fix, I choose a method to continue working on the go. When crashing, I delete the Dropbox’s file for sync my Scrivener project and create a new one. So I sync only the project in progress and one by one, I can wait three or four day after adding a new one in sync file. When crashing I repeat all the process.
I notice that :
– The project causing the crash not depending on his weight. The same project could causing the crash today and not the day after.
– The most remarkable thing is that, when crashing, on Mac, I slipping out my projects from the sync file and… On the IOS the sync doesn’t crash anymore and the project causing the crash is correctly sync. But of course it disappear at next sync because not more present in the cloud.

I started a new post as my issue seems slightly different, but perhaps connected to the same bug. But, I’m adding it here, too, hoping maybe they’ll get this fixed, or maybe someone following this thread would have some insight.
I am running iOS 13.2 on my iPad Pro 12.9 inch (from 2017, I think…).
When I tap the Scrivener app to open, I get the beginning screen (black with the Scrivener S) and then it shuts right off. I can’t even get Scrivener to start.
I’ve tried restarting my iPad a couple times, double checking the updates, but I’m not getting anything. My family has file sharing open, so even though Scrivener was purchased under my wife’s Apple ID, it should still work on my iPad (other apps purchased under her Apple ID still work fine).

Just letting everyone know that we are working on this behind the scenes. It’s fairly frustrating, though, in that we haven’t yet been able to find a clear reproduction case. It’s not project size or hardware-related: some people are fine with huge projects on older hardware, others get consistent crashes with moderately sized projects on Apple’s newest toys, and vice versa.

Reducing the number of synchronized projects does seem to help. But the issue seems to be related to the number of projects, not their size or contents.

Katherine

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 :smiley:

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.