Scrivener iOS syncing via Dropbox continues to crash the app

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.

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.

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

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?

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.

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.

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

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.
   
   
   

Part 2)

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

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

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

Thomas

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.

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

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

Have you tried tapping Cancel to stop and restart, or does the crash happen so fast that you don’t have time to do that?

[Edited for clarification (projects)]

Not sure this helps but anyway. I found a work-around to sync between my Mac and my iPad:

1. On Mac or iPad, I close the Scrivener project after working on it.
2. Sync on iPad invariably crashes during “file list” retrieval.
3. On Mac, I remove a random Scrivener project from the Dropbox sync folder.
4. On iPad, sync works fine now.
5. On Mac, I put the removed Scrivener project back & wait until it’s Dropbox-synced.
6. On iPad, sync again works fine. All projects are now synced.

I tried removing different Scrivener projects from the Dropbox sync folder—big ones, smaller ones, very small ones. Doesn’t make any difference. Sync always works after removing and putting back a project, respectively, no matter which.

But as soon as I work on any Scrivener project on my Mac or iPad, sync breaks down again and I have to repeat the above prodecure.

Cheers,
J.

iMac Retina 5K 27-inch (Late 2015) | macOS 10.14.6
iPad Pro 12.9" 3rd Gen | iPadOS 13.3

By “Scrivener doc”, do you mean a project?
(Anything else shouldn’t be in the sync folder in the first place.)

Yes of course, a meant project.

I’ll revise my original post to prevent misunderstandings.

Sometimes it happens very quickly, sometimes it takes a few seconds. To interrupt a process that is still running to start it again makes no sense to me. Either it works or it doesn’t work.

Wow, that sounds very elaborate and complicated. For me it wouldn’t be a viable process, even if it works after some trial and error. I mean, the synchronization process is either simple and fast, or it’s useless. I don’t want to fiddle around for hours to copy my project to the iPad, I want to write. I’m also writing this with the aspect in mind that everything worked fine before iPaOs 13, using the same hardware and the same apps.