Scrivener iOS syncing via Dropbox continues to crash the app

I have tried different things today like syncing smaller projects only, setting up the sync chain new, etc. It crashes each time.
Actually it doesn’t crash, to describe it correctly. The app is being moved off screen into the background, but without syncing and it is still active.
See screenshot.

I do not think it makes sense to play around further. I wonder if L&L has any news about it. Are they looking after it? Can they reproduce the issue? I have a bunch of writers in my forum who have exactly the same issue, so it’s not a single or isolated issue but a systematic problem.

Thanks for posting that. It almost looks like it may just be halting rather than crashing, which would be just as odd, but it clearly isn’t still running in the background since when you come back, the sync process needs to be restarted.

But this is one area where I’m not terribly familiar with the intricacies of how iOS works. I’ve always considered that “multitasking” screen to be more of a “Recent Apps” screen. On my phone I see stuff in there that is months old, and if I tap on the tile, the thing I activated obviously isn’t running and is booting a fresh session. Does stuff disappear from that view when it crashes, ordinarily?

That will never be the case. Please refer to this earlier post in this thread. Dropbox is just another method of moving data around.

That’s still something I wonder about, even though it seems to not be a major factor, one thing that is much more difficult to find patterns with is what the environment looks like, and how that impacts other heavy-duty processes like this. Thanks to the data you’ve all been contributing to this thread, it seems unlikely to be something solely on the Scrivener side of things. With full reinstalls having been done, full sync resets, there is little chance for odd variables like non-default settings, custom fonts, or other things that might be a trigger. It could still be content related, but it seems unlikely given that the trigger, for those that see it, seems more related to quantity than precisely which projects are involved.

Something like device model being newer is a factor of environment, so that is an interesting observation.

Some more tests I can think of:

  • To better rule out content-related issue: try using the Mac tutorial as test content. Duplicate it a dozen or so times and populate your sync folder with only that. Then proceed to test as you would with your own projects.
  • How loaded is the device; is there plenty of free space indicated in Settings: General: iDevice Storage?
  • And within that same panel, is Offload Unused Apps enabled, and if not, does enabling it change anything?

Obviously we’re still stumbling around a bit in the dark here. One last thing before finishing this post: if anyone has a reproducing case with a sync folder they would be willing to share with tech support in its entirety, something we could do is have you share that whole folder with us, so that it is linked at the account level, and then I could set up my device to sync to it from scratch and see if it crashes. Obviously that’s a leap of trust for anyone to take, and you’d definitely want to back that folder up since testing can be brutal to data.

None of us has seen this actually happen. If we could see it, it would probably already be fixed since such things are very easy to track down once they happen on a developer’s machine, with all of the debugging available.

I had only about 4gb of free memory on my phone, but I deleted a bunch of podcasts and now have 10 gb free. It still crashes.
I don’t think seeing it in the multitasking panel means it hasn’t crashed. When I „reopen“ from there I get a short startscreen with the Scrivener logo before the app starts again.

I found something that might be interesting. In the iPhone’s analysis reports. I have a lot of “JetsameEvent”. I have verified and they are created after Scrivener crash. The name of our app appears in the report . Perhaps the others can control whether such reports appear in their own device. If you think this useful, I can send a report for developers.

Yes, I also finally have a log file. Someone over at Facebook told me to look for a jetsam log file and there it is, Scrivener crashes and we get a jetsam log. I sent it to your support mail address. Hope this will help fixing the problem. I have other entries for other apps too, so the memory really seems to have a general problem.

I don’t know if it will work for everyone but I found a workaround that worked for me.

I created a new folder inside Dropbox
then I moved all my Scrivener projects from /Dropbox/Apps/Scrivener/ to this new folder
I opened Scrivener iOS and it didn’t crash.
Then I closed it.
I moved one project back in /Dropbox/Apps/Scrivener/
I started Scrivener iOS again and it synced this one Scrivener project without problems.
Then I moved back the other projects one by one and synced every time.

Amber, some of our Scrivener FB forum users have tried out to trace the crashes and Robert found a Jetsam-Entry in the log area of his iPhone/iPad, which always appeared after the crash. He saved it to provide it to your support team. Hope this helps.

Greetings,
Thomas

Sounds hopeful! I had seen one of these reports earlier, but it looked a bit like a generic system rundown rather than something specific to Scrivener, so had put it aside. Having a few additional samples of this kind of report may be helpful, please do send them in.

If it is memory related, something to try is to fully restart the device by holding down the power key for a few seconds, then swiping off on the screen. Reboot the device, and go straight to Scrivener and try syncing.

Yes, he did send it already …
Meanwhile, I switched back to the good old times and copied the project file I am working on via iCloud and the iOs filemanager into the Scrivener directory. It works fine and the project file can be opened. (I disconnected dropbox before this exercise.). I know, it’s a manual task and I have to copy it back when I’m done and this is not very comfortable, but at least a workaround.
Maybe it’s time to implement an iCloud sync for the next release?
It seems to work better than in the past.

Greetings,
Thomas

Still crashes after restart …

I tried gcg’s method, and it worked for almost all of my Scrivener projects. Looking at my projects Scrivener crashes on those two projects with more than 100k words and more than a thousand files to sync (according to info I got from “show packet contents” on my Mac). So, maybe it’s the number of files to sync that causes the crash? Just my two cents.

Have it as well here.

iPad Pro 2018, iOS 13.1.

EDIT: Just did the update to 13.1.1, but still crashes.

I have good news and bad news.
The bad news: There was an update to 13.1.1 today, but it didn’t solve the problem.
The good news: I dared to upgrade to iOS13 on my iPad pro and Scrivener doesn’t crash here!
But of course, this is once more mysterious, since I have the exact same projects that crash on the phone but work on the iPad.

13.1.1 has not helped here.

The synch still fails and Scrivener drops to background app on iPad Pro 12.9 2018.

Strangely upgrading my iPhone X to 13.1.1 synched fine then a follow up synch failed per the iPad, then another synch worked.

My iPad Mini5 2019, iPadOS 13.1.1 crashes
My iPhone SE 2017, iOS 13.1.1 doesn’t crash

I tried this today, copying a dozen tutorials into a Scrivener test folder, syncing with the iPhone after each copy, and then syncing with the iPad Pro once all 12 tutorials were copied into the new folder. Both those processes have been crashing Scrivener on the phone and the iPad to this point. But today … everything is syncing fine (with tutorials as content only).

Still crashing on both my iPhone 11 Pro (13.1.1) and my iPad Pro 11” (13.1.1) when trying to sync.

I’ve always found Dropbox syncing flaky and inconvenient. Plus I only have 2GB with Dropbox - their paid tiers are overkill and too expensive for me, whereas I only pay 79p (99¢) a month for 50GB iCloud. I’ve used Scrivener for a long time but I need reliability and consistency which I believe comes with iCloud integration. I’m aware of the technical issues but as a writer my priority is writing and not troubleshooting so, with regret, I will have to move to another program. My only intention here is to add to the voices requesting some way of using iCloud in the future. At that time I will gladly return to Scrivener.

Obviously, YMMV. Plenty of Scrivener users have a smooth experience and I guess plenty are not having this current dropbox problem.

After updating to 13.1.1, deleting my scrivener app and reinstalling/re-linking dropbox I am able to sync smaller projects (from 590kb-7.9mb) from the default folder only: Dropbox/Apps/Scrivener

I wasn’t able to sync a tutorial copy outside of the default folder (for example: Dropbox/Scrivener) even after above steps.

My two larger projects are still crashing the app if in the default folder (33.7mb and 165.1mb)

iPhone XS Max 13.1.1

I have tried again today, but any attempt to sync via DropBox leads to a crash.
I guess it is time to implement a process to syc projects via iCloud. :bulb:

Some more follow-up on this bug:

Firstly, resetting the sync cache does not solve the issue.

Secondly, the bug does seem to be bound up in the reading of sync files by the Scrivener app in its interactions with the Dropbox app api in iOS. For example, when the entire sync environment is reset (removing all sync settings, deleting the dropbox folder formerly used, creating a new one and setting up sync anew with that), this restores operability (the sync will work correctly with a blank folder) — but if all the project files are restored to to the new folder, the crash resumes. However, if they are added back one-by-one and a sync performed each time (i.e. after each project file is added, one by one, to the folder), before others are added, the syncs will work each time, incorporating the new projects one by one, until all are added.

To put this another way (assuming for the moment that I had three project files in my former sync folder): after resetting the entire sync environment in the iOS app and linking it to a new, empty, dropbox folder:

A) Adding project files 1, 2 and 3 into the new dropbox folder all at once, and initiating a sync within iOS = bug resumes and the app crashes out as described in the original post.
B) However, adding Project File 1, then sync, then add Project File 2, then sync, then add Project File 3, then sync = all syncs perform correctly, and thereafter the app will sync properly with all the files in the folder.

What is curious about this bug is that it isn’t the case that one or another project file is causing the crash: as just explained, route B involves ending up with all the same project files included (in my actual install, I have 16 project files syncing in the folder) — it is having them all together when switching to the new iOS app, new iOS version and Dropbox version, that causes the crash.

Curiouser and curiouser…

T.