Can anyone tell us what devices L&L are using for testing? Because reading this thread, it seems pretty obvious that the issue is bound to certain devices under certain versions of iOS/iPadOS (like, the latest?), except maybe for the 12-inch iPadPro. Do they even have the right devices to test for that issue? Because if they don’t, it’s no surprise they can’t replicate it.
I haven’t tried it (because I, like most of the people coming to this forum, am very busy writing and don’t have time to do debugging for an app that I paid) but from my experience, duplicating the tutorial enough time and syncing it would be enough to trigger it, seriously.
It happens so much and with so many different kinds of projects that if you have the right gear to test with, I feel like it’s impossible not to replicate it. So my question is : with what devices are the L&L people testing?
It happens only on iOS 13 and iPadOS, but otherwise, there’s no reliable pattern.
There has to be a piece of code somewhere in iOS 13, just ONE LINE perhaps, a line used by the Dropbox API, that fails on a random selection of CPUs, many of which SHOULD be identical. Very bizarre. Perhaps it’s determined by other apps installed, but that would be odd.
That line of code can’t be cornered and identified without a reproducible case, and Literature & Latte doesn’t have one in hand.
Just a shot in the dark, but I’ve not seen it mentioned and it’s easy to check…
iOS 13 introduced a feature for cellular and Wi-Fi called Low Data Mode. I’ve read that for some iOS users when they’ve enabled then disabled it, it has reenabled on its own. The feature is set per network and the Wi-Fi preference (cellular too?) gets synced via iCloud. I’ve done limited research and have not found thorough technical information about the feature. General information, including how to enable/disable, from Apple:
“You might want to use Low Data Mode if your cellular or internet plan limits your data usage, or if you’re in an area with slow data speeds.”
That could be useful or not depending upon user location and conditions at a point in time, and of course, if it actually works properly with each piece of hardware/circumstance for which it’s available.
Maybe it depends on how many users that are afflicted by it? Is it one per 100 users, or one per 1000 users, or maybe only one in 10 000 users, or even less?
We have no idea. Only L&L knows.
I’m also affected. Sync doesn’t work anymore, neither on my iPhone 11 with iOS 13.2.3, nor on my iPad Pro 3rd Gen 12.9 with iPadOS 13.2.3. It says “Downloading file list…” and then invariably crashes.
So I can’t use the mobile version anymore.
P.S. just updated both devices to 13.3, doesn’t change a thing.
Do you want to give up your device and your iCloud account? Because it’s likely some combination of device, OS, iCloud account, and project that triggers this bug…
Yep - count me in the number effected! So annoying. I’ve tried all of the suggestions, and they don’t work, L&L need to get an update happening pronto to fix this issue… Because without the functionality of syncing - then the app is pointless…
You can sync manually with iCloud and the Files app:
Put the project in iCloud, wait for it to sync, find it in the iOS Files app, and open it from there.
To go the other way, click Edit on the home screen, select the project, and click the export (up-arrow) icon at bottom of the screen. Scrivener creates a zip file and iOS offers to Send it in various ways (like Airdrop, Dropbox, Messenger, and Files).
If you export the Zip file to Files (may have to Edit Actions to add that option), you can choose to put it in an iCloud folder.
You don’t even need to zip it after working on it.
So I open a project from the Files App. It will ask me to copy to ‘On My iPad’. If you already have the file downloaded in the Files App, this will happen super quick, even for 10GB projects.
After working on it on the iPad, I open 2 Files-app windows in side by side. On are my Projects on iCloud. The other one is the folder On My iPad - Scrivener. There you can find the local projects. If you just drag and drop from there, you don’t even need to zip. It will ask you to replace the old project on your iCloud folder, if the old version is still there.
I’ve been using this method the past 3 months, and it has been reliable and quick, but it IS a manual process and not a sync.
I think that’s how the Dropbox API is written, and that’s the one Scrivener relies on. Scrivener doesn’t have it’s own sync code, it uses the Dropbox API to let it take care of the syncing (if I understand correctly). The Dropbox API first makes a list of all the files, and that is what is taking abnormally long since the update to Scrivener 3 (which in turn created 2-2.5 the amounts of files internally in a project compared to the previous version).
And now we have the whole crash issue, but this is a weird one because some people have it on small projects, some on big projects, some have it on newer hardware but not on old hardware, with the same projects, so…
We still to this day, 3 months after reporting the problem, don’t know exactly what the problem is, and where it lies. Just (calculated) guesses.
Hunting around the Dropbox forums turns up a lot of posts with hangs related to downloading the file list, which seem quite similar to what we’re having here. I’m wondering if there’s been a change in the Dropbox API that’s made this problem manifest itself for Scrivener users.
There hasn’t been a fix for the problem, but it seems it’s related to the length of the path for a particular file being synced, and a few people have got around it by shortening filenames and shallowing hierarchies.
So, assuming that this hasn’t already been mentioned in the last 22 pages, has anyone tried the following:
Take a project that is not syncing and make a copy of it.
Start with the longest path in the hierarchy (could be a really deep path structure or a really long file name or both) and remove it.
Remove the Scrivener app from Dropbox sync and add it back in again.
Try syncing the project.
Go back to step 2 (Repeat with the next longest path.)
I’m wondering if you get to a point where the project will eventually start to sync.
How is it supposed to know what files have changed? Keeping in mind that there may be changes to both the local and the server versions, and users expect Dropbox to keep track.