Scrivener iOS syncing via Dropbox continues to crash the app

[sthomson2]

Amber,

I have been corresponding with Pascal on this issue a bit. I have two iPhones, one two years old and one brand new, both experiencing the issues described in this thread. Scrivener runs fine on my iPad Pro.

I would be willing to show you what is happening in a Zoom session, using screen sharing, and to walk through troubleshooting steps, if it would help to arrive at a solution.

Thanks for your continued diligence at solving these issues. I know how frustrating it can be working with operating system upgrades.

Seth Thomson

[AmberV]

Thanks for the offer, Seth! Unfortunately I don’t think that would help us, since we pretty much have a good idea of what it looks like on the surface, and the kind of data the OS produces beneath that. These two aspects can provide clues as to the nature of the problem, but very rarely will they provide precise information on what happens—for that you basically need a live case physically plugged into the Mac that has Xcode and the source code for Scrivener running in debugging mode. Sometimes you can find problems in the simulator as well, so you don’t need the physical setup, but as I say, we have yet to see it happen under any conditions.

And that’s even assuming debugging can pinpoint the problem—in a case like this it has every indication of an OS memory bug or flaw causing it to erroneously shut down Scrivener. We can detect no out of the ordinary memory usage under normal circumstances, even with the exact same data used to trigger the problem elsewhere.

So without that, there is no debugging. All we have is a relatively simple loop that has worked flawlessly for nearly four years, until suddenly iOS 13 comes out (to be very generous, I’m still calling it a beta) and now some, but not all, devices mysteriously don’t have enough RAM to finish doing something an iPhone 4 running iOS 9 had no trouble doing.

[dberreby]

I have 13.2.3 and it did not fix the problem. I think, like me, many have given up on syncing to iOS or have been using the manual solutions suggested elsewhere. It sounds to me like it's a memory allocation issue as some have suggested. Whatever it is, it isn't fixed.

This is exactly where I am on the issue. I have given up sync on my iphone XR running 13.2.3. It is not worth the time, stress and frustration to keep returning to this issue. Scrivener syncs fine on my newer and older Macbooks, and on my iPad. As these are the devices I use to actually write, I decided I could live without the ability to access projects on a phone.

So I think you are right. Silence means people have moved on, not that the issue is fixed.

David

[kewms]

Thanks Amber for the update.
What I read was that L&L has no idea about what happens and is not working closely with Apple to solve this unknown problem for us unfortunate customers.

This was unfortunate news for an otherwise lovely app.
/A

"Working closely with Apple" is rather more difficult to actually do than to write. They are not the most responsive company in the world, even for developers.

As Ioa notes, though, the first step toward solving the problem is reproducible test case. So far, we don't have one.

Katherine

[iPersuade]

some, but not all, devices mysteriously don’t have enough RAM to finish doing something an iPhone 4 running iOS 9 had no trouble doing.

Are you sure the issue is RAM? I've been having this issue on my iPhone 11 Pro, but not on my two-year-old iPad Pro. I've tried a series of troubleshooting steps, but nothing has yielded any promising leads. I tried the create-a-new-Dropbox-folder-and-slowly-add-back-the-projects-like-a-Scrivener-soulfé method. But it has not worked for me--it has worked in part, but eventually I add in a project that causes the sync to crash the app again (seemingly no rhyme or reason as to which project). At first I thought the problem was because, in my Scrivener sync folder, I have some legacy non-scrivener files. But removing them did not ultimately eliminate the sync error.

The only thing that I have observed consistently--and this may be something you are already aware of--is that the actual syncing does not seem to be the problem. The app hangs during the sync phase where it is "downloading file list" from Dropbox. If it gets past that phase, I've never experienced a crash. That made me think it's something other than a RAM issue (how much RAM can a file list take?), but I'm no developer so take this diagnosis with a grain or so of salt.

The other thing I've observed that may be related has to do with Scrivener's settings from the iOS settings app. If I go into those settings and try to toggle a setting, it crashes the settings app. If I re-open settings and go back to the Scrivener settings, it does appear that the toggle I adjusted was correctly set despite the settings app-crash. Maybe that means something to you?

Hope this is of some help in diagnosing the problem. I'm happy to try other troubleshooting methods. I would offer to do the settings reset, but I had to do that recently for another problem.

I know this must be frustrating for you -- a problem you haven't experienced and cannot effectively recreate and test coupled with very vocal and upset users. Scrivener is an exceedingly well-engineered app because its development team is diligent, disciplined, and very attentive to detail. I have no doubt you want this problem fixed as badly as we users do. I am grateful for your efforts and look forward to having sync working reliably again.

[AmberV]

The only thing that I have observed consistently–and this may be something you are already aware of–is that the actual syncing does not seem to be the problem.

Yes, that is all a known part of the pattern. It’s probably a few pages back in this thread at this point.

That made me think it’s something other than a RAM issue (how much RAM can a file list take?), but I’m no developer so take this diagnosis with a grain or so of salt.

Well, there is quite a lot to unpack in there. One can write an horrifically inefficient loop that copies the entire hard drive list over and over in its attempts to map the territory. But it should go without saying that we haven’t done that, and the loop that has built this list for years now is pretty much the same loop that was optimised to work on very old hardware—so it’s pretty efficient. The problem is almost certainly not with the loop.

The joke then (which to be clear is all it was) is that iOS produces a memory use threshold error log when shutting down Scrivener, on devices that have way more RAM.

So to say it’s not a RAM problem is… well, it’s more complicated I think. It’s not, obviously a matter of the size of one’s chips—that is mathematically true and self-evident—but to say it isn’t a memory problem because of this (or inversely that the process should be small) probably isn’t a safe assertion. It may be that the memory problem is false, that iOS thinks it is running out of RAM when it isn’t, but even so that is still kind of a memory problem, or at least a problem in the infrastructure of the device that deals with memory.

The other thing I’ve observed that may be related has to do with Scrivener’s settings from the iOS settings app. If I go into those settings and try to toggle a setting, it crashes the settings app.

This has confused the topic at hand. I’ve split it off to a new thread.

[throthberghofer]

:cry: No success either, at least not on both of my iPads after installing iPadOS 13.2.

iPad Pro (12.9 inch) ➜ successful sync
iPad Pro (11 inch) ➜ crashing like before

Installed 13.2.3, moved one of the problematic projects to my sync'ed folder, but same result:

iPad Pro (12.9 inch) ➜ sync'ed successful
iPad Pro (11 inch) ➜ crashed

No improvement. Installed 13.3. iPad Pro (11 inch) still crashes.

[Thomas Rabenstein]

Hello all,

I just upgraded my iPad to iPadOs version 13.3. At the same time an update for the Dropbox arrived today. Unfortunately the problem persists and Scrivener says goodbye while the app downloads the file list. The actual synchronization process hasn't even started yet when it crashes.
If I empty the dropbox directory on my Mac and synchronize an empty directory without project files, the synchronization will run without a crash. It doesn't help me, but shows that the crash is actually related to loading or synchronizing the directory content.
I still hope that this problem can be solved. If we, the users, can help the developers in any way to identify the cause, please feel free to ask.

Greetings,
Thomas

[GrahamGrün]

All we have is a relatively simple loop that has worked flawlessly for nearly four years, until suddenly iOS 13 comes out (to be very generous, I’m still calling it a beta) and now some, but not all, devices mysteriously don’t have enough RAM to finish doing something an iPhone 4 running iOS 9 had no trouble doing.

Sorry, but that’s not really true. There has been the problem of the „downloading file list“ taking extremely long after upgrading to Scrivener 2, which as far as I followed up was never really resolved or explained. I hate to say it, because I really love Scrivener, but my impression is that the database just isn’t made for syncing and the workaround you found is just to complicated to work „flawlessly“. The software is great on the Mac, but it doesn’t seem to evolve with the trend to switch devices seamlessly.

[AmberV]

Let’s try to keep this thread focussed on the actual bug at hand here. It just makes things confusing when completely unrelated topics are brought up.

GrahamGrün: Sorry, but that’s not really true. There has been the problem of the „downloading file list“ taking extremely long after upgrading to Scrivener 2, which as far as I followed up was never really resolved or explained.

The explanation might have been lost in a long thread about it, but the source of the problem was indeed pinned down and reported to Dropbox some time ago. Since then I’ve heard that performance has improved marginally, and they even communicated with us that it is something they are aware of and wish to improve. The technical explanation has to do with how their API has a lot of overhead when trawling a folder hierarchy. The more folders you have, the longer it takes to build a file list.

I know in my recent testing it did seem to be a lot better than it used to be. I ran some tests with over 10,000 folders to be synced, and while it took a while to build the file list, it wasn’t anything like it used to be.

Again, this is not in any way relevant to this current problem, which is all I was speaking of.

I hate to say it, because I really love Scrivener, but my impression is that the database just isn’t made for syncing and the workaround you found is just to complicated to work „flawlessly“.

An interesting theory, but no. For one thing, it’s not a database, and the format itself was designed from the ground up for syncing. So scratch all of that. Secondly, what we’re talking about is a simple request for a full file list from a folder. This is the first thing you must get from the server when syncing files: a list of files. That is not a workaround, that is how you work. It is also not complicated—it is a request for files from a file system. That the server takes forever to produce this list does not speak to “flaws” in the system.

[GrahamGrün]

Okay, sorry if I made stupid technical assumptions. But it remains true that syncing is tedious, even without the bug. Maybe you just can’t have both: the greatness of Scrivener and an easy, seamless user experience when switching devices.
The way I work involves many short writing episodes during the day on whichever device I‘m just at. My phone is useless for some time now. Maybe I just have to accept that Scrivener isn’t made for my use case.

[lunk]

But it remains true that syncing is tedious, even without the bug. Maybe you just can’t have both: the greatness of Scrivener and an easy, seamless user experience when switching devices.

Syncing is tedious... for some users, not all.
I have had a ”seamless user experience” since day one. So how come it works for me and not for you?

[KillerWhale]

Lunk, would you have the kindness of not dismissing other’s bad experiences nor imply that it may somehow be their fault, please?

[lunk]

I'm not dismissing it and the question is a question.
If some have problems and some don't, the differences between our use cases should be of interest in trying to find the cause.

Several users have reported problems, but if a majority of the users had problems L&L would be drowning in complaints, and they're not. So far the reactions in here suggest that a minority of users have problems, so the important question should be "in what way do their set up differ from those that don't have problems?"

If it is total number of files in the synced folder, then it should be interesting to know if there is some kind of breaking point and/or if that changes depending on device, or depending on connection speed with the Db server, etc.

In my case, I have lots and lots of Scrivener projects, but only 6 in the folder I sync with my iDevices. The total size is usually less than 50 Mb (only text no images) and the total number of files usually below 1500. No syncing problems.

Killerwhale, what does your scenario look like?

[sidderke]

.So how come it works for me and not for you?

I also had problems. We are trying for months to get answers and solutions but nobody has them.