Hmm. Could you clarify the specific sequence of events, please?
That is, was it (Scenario 1)
Sync project A in Scriv 2 format, all is well.
Convert project A to Scriv 3 format.
Crash
Or (Scenario 2)
Convert project A to Scriv 3 format
Sync
Crash
The question being if the problem comes when converting a project that’s already been synced. The new format is a substantial change to the project structure, so converting it would force the sync step to essentially replace the whole thing.
So, if the series of events was as in Scenario 1, here’s something to try:
Move the project out of the Dropbox folder on the computer.
Synchronize, which should remove it from the iOS device entirely.
Move it back and see if it synchronizes successfully.
Scriv 2 doc was synced. I made a copy and converted to Scriv 3. Both the back-up and converted file were in the sync folder when it crashed. I deleted the ios app for a clean download and it kept crashing.
As suggested above;
I moved the files in question out of the sync file. All other files synced like a charm. Added the Scriv 3 file and it crashed. Took the Scriv 3 file out and tried the Scriv 2 file, no problem syncing. Not sure that it helps but I have many other Scriv 3 files that sync fine, just the one file is a pain (perhaps the size?)
I made another Scriv 3 copy of the file. It’s crashing on sync.
I use DropBox and Scrivener on both PC Windows 10 Pro and MacBook Air running the latest version (14.15.2?) and have experienced no problems with either DropBox or Scrivener. I move back and forth between operating systems seamlessly. My desktop is Win10 and I use interchangeably my MBA and Lenovo Laptop running Win10 Pro.
The only trick I’ve learned is to go into the default installation of DropBox and uncheck the option to throttle uploads, which is checked by default. What you’ll find is that making changes takes sometimes minutes to upload and you get corrupted data in the cloud.
Go into Preferences | Bandwidth and set both Download and Upload rate to “Don’t Limit”
I always make sure that before I close the lid on my laptop, I look at the DropBox icon and make sure it says “Up to Date”
This is my first post in this thread, and I’m just writing into to politely express my frustration not just with the syncing issue, but with the tone of the response from L&L. I’ve been a user of Scrivener since nearly the beginning and have turned over a dozen other people on to it. It’s an amazing piece of software.
However, both my iPad (11" pro) and iPhone (XR) have been crashing on sync attempt in Scrivener ever since the iOS upgrade. I understand that much or perhaps even all of the issue/fault is with Apple. Fine. But what I don’t get is why L&L representatives on this forum – in this thread – are so dismissive of the issue and the people who have it. It feels as if they are attempting to aggressively minimize it and portray the people who have it as rare and almost as trouble-makers who are stirring the pot by harping on and on about their supposedly rare issue. I believe it is a lot less rare than you think. And even if it is uncommon, please take it seriously and treat your users with respect.
I have just configured a newly bought iPad Pro 12.9 (3rd gen.) with iOS 13.3 and get the “sync-crash”. It says “Downloading file list…” and then the Scrivener app closes (resp. vanished into the background and sync stops unsuccessful).
My two other iOS Devices with iOS 13.3: iPhone 8 plus and iPad Pro 12.9 (1st generation) sync without problems which might indicate that the problem is device related.
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.
”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.
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.
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?
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.
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.
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.
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