Scrivener iOS syncing via Dropbox continues to crash the app

Scrivener Scrivener for iOS
361

Have you isolated your files that cause the crash and submitted a copy or at least details to support?

362

Not a comprehensive listing, but probably enough reading material to get one up to speed on the status:

363

I don’t see any progress on the problem and read again and again, L&L can’t reproduce the abort during synchronization. Did the developers get a last generation iPad to reproduce the process? It is becoming increasingly clear that mainly current devices with current iOs are affected. According to a survey in our authors’ forum (700 users), about one third of iOs users complain about the crash while synchronizing and the level of frustration slowly increases. None of the solutions discussed so far is reliable or suitable for larger writing projects. I can’t use Scrivener for iOs at the moment and the expensive iPad, which I bought especially for writing on the go, is gathering dust on the shelf. I hope for an early solution.

364

”Mainly” is not specific enough. It could actually imply something completely different, e.g that mainly users with complex projects or a lot of background updating apps are hit by the problem.
My new iPhone 11 pro behaves just as well as the old 8, and the same goes for the iPad.

365

I’m not sure what you mean by your reply. Everything worked perfectly on my iPad before the update to iOs 13, now it doesn’t work anymore. And like me, there are a lot of users right now. Whether my statement was specific enough or not doesn’t really matter. It’s starting to feel as if the problem is considered minor, and that it’s not being treated as a priority because it seems to only affect a minority. That disappoints me.
If you are one of those happy users where everything works, I am happy for you. But it doesn’t help me.

366

It’s not affecting newer devices per se. But maybe people with newer devices have more complex use cases than people with older devices? Apps using more memory?

367

The only pattern is that it started with iOS13 and iPadOS … and Apple soon made it hard (even harder than it used to be) to downgrade to iOS12 or earlier. Counterexamples have debunked device-dependent and project-dependent theories, other than it SOMETIMES helping to reduce the number of projects in the sync folder.

If some people have more apps or they’re doing more complex tasks on their devices, that’s impossible for Literature & Latte to track in a rigorous way at a distance.

They haven’t seen the bug occur in front of them, so I find it hard to believe 1/3 of all users are affected, or even close.

After almost 4 months, this thread has less than 400 posts, most of them (a) duplicates from the same user, (b) Literature & Latte posts, and © posts from folks like me, who don’t have the problem. I’m moderator on a Scrivener group of over 12,000 users, and I’ve seen maybe THREE of them mention the problem. Almost no one comments on threads I started on the subject. 12,000 users, and not ONE of them started a thread.

That doesn’t mean it’s not a problem … even if the true number is 1/10,000 … but it makes solving it difficult. Any software engineer will tell you reproducing the problem in a laboratory setting, with professional debugging tools, is KEY to solving tricky problems. Literature & Latte doesn’t have a test case.

If the true numbers are what I suspect they may be, it’s comparable to the odds that a faulty section of the memory chip is key to getting the job done in a loop of MANY calls to the Dropbox API. iOS 13 may have made an unfortunate compromise on performance vs. error-correction.

If that is true, Apple will eventually find it and fix it, but Literature & Latte cannot.

368

Don’t forget that Scrivener 3 may also be a component of the bug.

Some people are here saying it especially happens with projects that started with Scrivener 2 and were upgraded to 3. I noticed (and also made threads about it) that what on the same older hardware and same older iOS used to take 4 seconds to ‘download file list’ suddenly became 5-15 minutes. For the same projects, but just upgraded to Scrivener 3.

The kind of conclusion (but not solution, because there wasn’t any) was that Scrivener 3 about doubled the amount of internal files a Scrivener project had. (which, in my case, when you have big projects with lots of files, it amounts to a lot.) Now, the weird thing was, that my ‘download file lists’ time didn’t double. It went from literally 5 seconds to 5-15 minutes, depending on hardware. The conclusion of the thread was that the Dropbox API took a long time to download the file list, and it seemed like it suddenly hit a wall with the amount of files people had.

Now there is the crashing. Maybe it is a combination of Dropbox API, background processing in iOS 13, and the amount of files Scrivener 3 generated in comparison with Scrivener 2. It’s difficult, and I understand that it’s difficult for the engineers to troubleshoot. I love the software, but I also can’t deny that from the perspective of this user, using the iOS app has been an often frustrating process because of these problems for years now. It was different in the beginning, even on older hardware, and even with just as big projects.

I now use iCloud to manually transfer files from iPad into the Scrivener App. Yes, it’s a manual process, but it botters me less because at least it works and it works reliably.

369

Sadly, this also appears to be a red herring. I asked a user with this issue to import the files from a failing project into a brand new Scrivener 3 project, on the theory that doing so would clean up any artifacts remaining from the conversion. Didn’t help. My guess is that it’s not Scrivener 2 as such, but that older projects are also more likely to be big, complicated, and otherwise have whatever characteristics trigger the issue.

Katherine

370

Regardless of its origin, a Scrivener 3 project has its documents a level lower in the file hierarchy than before, in folders with 36-character names. Even if the pathname length doesn’t matter, you’re searching those folders, which didn’t exist in Scrivener 1 or 2. That’s a more complicated loop, potentially. (Visually at least, the file structure is far more complex.)

If the failing project is always Scrivener 3 or the Beta, that’s a solid theory.

How many users in this thread have named the version involved?

371

More complicated probably isn’t how I would put it. The loop just gets a list of files at one level, notes which are folders, and then works through the list of those, and on and on until it runs out of folders to scan. The complexity of this process does not change if you add an additional layer of hierarchy—it merely changes the length of the process. And to reiterate, that is the only part of the process that iOS is giving up on: a recursive trawl of a relative basic (in the grand scheme of things) folder hierarchy. This problem is not even technically within the realm of synchronisation.

The long delay was a matter of poor optimisation in Dropbox’s server side and has largely been cleaned up at this point (they could still do better, but it’s nowhere near as bad as it was). As I’ve expressed before in this thread, it is extremely unlikely that a server side Dropbox optimisation issue has anything at all to do with a specific version of iOS running out of RAM (or at least thinking it has run out of RAM). I don’t understand why, four or five pages later, it is being posted again as maybe still being an issue.

As Katherine notes, there are a lot of factors I see being reposted as maybe being issues that aren’t actually issues. We’ve eliminated most of what seemed to be patterns, early in the process. All we really know is that iOS 13 has a fickle resource management routine that only backfires in some contexts (where context is a nebulous concept that could span from extremely specific hardware characteristics that aren’t model related, to installation patterns, to settings made, to things I’m not even thinking of here). That’s about it!

There is an extremely important difference between not having enough data to solve a problem, and every indication of the problem being on the OS side—and not treating it as a priority for… whatever reason (I can say that in general we don’t rate bugs on commonality but severity, so your assertion that we would let something slide because only some people experience it is false). The latter is a speculation made on your part, and I would say is clearly rebutted above in my listing of posts. We have given the matter as much priority as we can—far more than we have many bug reports in fact. But after a certain point, without any data, what you’re suggesting we continue doing is what we would all refer to as banging one’s head against a wall. It serves no purpose.

There are still more avenues for gathering data, but most of them are so extreme, to date nobody has tried them (nor do I blame anyone for not doing so). Spending half a day backing up, factory resetting, testing and then restoring your device is a lot of work. But it would serve to provide a valuable look into the matter of context, particularly if that clean slate device works, and then can be shown to stop working as its original level of functionality, both in installation and configuration, is gradually restored. It’s the kind of test we’d do ourselves if we could.

372

USERS OUT THERE, IF THIS BUG AFFECTS YOU:

Ioa is suggesting something you can do to help yourself and other users.

I think she means wiping the device, installing Dropbox & Scrivener only (to the extent Apple makes it possible), and seeing if the problem is gone. If it is, install apps one at a time until the problem recurs, keeping track of what happens at every step. When the problem returns or everything is installed and the problem hasn’t returned, send her the results.

It’s what she’d do if she had a device that exhibits the problem.

373

Hello, Amber,
I’m currently working on the Mac and performing a factory reset on the iPad to take up your suggestion.
I delete the entire iPad and reinstall the dropbox and Scrivener from scratch.
For the test phase I’ll leave it at these two apps to see if any other app has affected the behaviour.
This can take an hour and I will contact you with the result and all details.
Greetings,
Thomas

374

Hello, Amber,

I am then ready to post the result after resetting the iPad:

After the factory reset and the complete deletion of the iPad, I have set up the tablet again.
The data:
Model: iPad Pro (12.9 inch, 3rd generation)
iPad Os: 13.3
Storage capacity: 256 GByte
Apps: Only the standard apps

  1. New installation of the Dropbox App on the iPad. Drobox folder on the Mac is empty. I copy two project files into the Dropbox folder. One is very small < 40 MByte, the second is my current project > 240 MByte. I wait until the files are completely synchronized and appear in the Drobox app on the iPad.
    IMG_0010.jpeg
    IMG_0002.jpeg
    IMG_2149.jpeg
375

Part 2)

  1. New installation of the current Scrivener version for iPadOs.
  2. Scrivener connected to the Dropbox App
  3. Synchronization started
    …
    The synchronisation hangs in the “Download file information” loop for a very long time.
    IMG_0012.jpeg
    IMG_0011.jpeg
    IMG_0006.jpeg
376

After a long wait, during which nothing happens and the synchronization gets stuck at the “Download file information” step, the Scrivener App disappears from the screen and the process is aborted. The app still appears in the process list, but the process is aborted or, rather, it has not been started at all. The abort occurs before the actual synchronization starts.

Greetings,
Thomas
IMG_0014.jpeg
IMG_0013.jpeg

377

Just a thank you for taking the time going through all the troubles. This is very much appreciated.

Thomas

378

A detail: although sync generally works for me, the process sometimes hangs and nothing seems to happen. When this happens I always tap Cancel and restart the process, and this is usually enough to get it going again.
It seems there are actually two different issues that occur. Immediate crash when sync is tapped or a long delay waiting for some process, whereafter it crashes.

379

Hi Thomas,
The factory reset was actually the only procedure I had not yet tried. Of course, the driving force was the hope that it would work again afterwards, but unfortunately it didn’t work. The problem remains.
Greetings,
Thomas

380

No, unfortunately, that is not the case here. The process always breaks off, the first time it takes longer, the following attempts are faster. It is the same effect as before the factory reset. And once again emphasized, the synchronization worked before (under iOs 12) without any problems and reliably, no matter how many project files were in the sync folder or how large the files were.
Greetings,
Thomas