Slow sync sending files from Android

@ranayas?

https://github.com/marbens-arch/syncthing-android/releases/download/v2.0.3.90/com.github.catfriend1.syncthingandroid_debug_v2.0.3.90_0d05186.apk

Please set up from scratch without importing your settings.

This uses SyncthingNative 2.0.3 with the following changes:

  • Revert ac8b3342ac9d9fcd2df8655a62bfa2ffb505ab42
  • Revert cbe1220680fc3d05688aae77e9a50581e669d1be (as this depends on the other reverted commit)

This version fixes the stalling for me. ac8b3342ac9d9fcd2df8655a62bfa2ffb505ab42 is the commit that git bisect said is the first slow commit.

I used this command to generate a (random) dataset for triggering this bug:

for i in $(seq 1 3400); do dd if=/dev/urandom of=/sdcard/dummy/$i bs=10M count=1; done

The dataset I got from that was particularly good for this purpose because it stalled at the beginning in problematic versions. I can distribute the random dataset I got, if that matters to anybody.

Sure will try it out over the weekend @marbens

1 Like

Sounds like the caching removed by chore(fs): only cache the cache for case FS, not the entire FS by imsodin Ā· Pull Request #9701 Ā· syncthing/syncthing Ā· GitHub acted as an unintended stopgap solution for Androids abysmal IO performance?

@marbens your test methodology sounds good. Could you create a support bundle for a stalling run?

Actions → Support Bundle

Here’s the receiver side (Arch Linux):

support-bundle-7U2LOM2-2025-08-28T085420.zip (48.9 KB)

Here’s the sender side (Android):

syncthing-support-bundle_sender.zip (62.7 KB)

The title of that PR isn’t that great: Cache wasn’t removed, it’s just a refactor still caching the cache. However I do remember there was brokeness in the main branch (not stable releases) at some point, so if you are bisecting commits you might run into that.

I’m a new user to syncthing, but have faced the slow android sync on one of my devices for a folder of: 666 files 82 folders ~99.1 GiB.

I sorted it with 1.9 version apk, but I’m willing to nuke it and do some more testing as I have a few such devices, my other main one that receives this whole folder did not have this problem.

1.9 has a fair few inferior bits to it.

Want me to do any testing?

edit

Deleted my data folder on the recipient and I’ve fired up the debug apk above out of curiosity. It’s going fairly slow vs v1.9 - which maintained a steady 60-80 MB/s and got it all done in 20- 30 mins.

This one is spending a lot of time at 0.0MB/s and jumping up to 80MB/s occasionally for a little burst, then back down again. I’m 15 mins in and have got 11GB done (average of 12 MB/s). It is more stable than the previous latest version I used though, that kept stopping completely if I left the device alone.

will report back with more later. If you want any logs or anything let me know (maybe with some instructions if it’s more involved than the basic logs!)

Here’s a support bundle from when it was chugging along slowly.

syncthing-support-bundle_RG477M.zip (88.1 KB)

I can honestly say for me this version is no better than the latest fork. The connection issue was my device sleeping rather than anything else related to the slowdown. I’m 1.5hrs in and it’s done 40GB. going to stop it soon.

@Zamzoo To be clear, are you sending from Android or sending to Android? This thread is about sending from Android.

I renamed the topic, because it seems to be on the Android end, and it looks like it would have an effect no matter the OS on the receiving end, and to emphasize the direction of sync.

Ah, no. I am sending from Unraid to Android, and it’s unbelievably slow. version 1.9 fixed it though…. maybe it’s the same issue?

Damn, I thought the issue I was having was nearly resolved there :smiley:

If 1.27.12.0 doesn’t fix it, it is not likely to be the same issue.

Here it is (from archive.org because that release got deleted, and is not in the ā€œSyncthing-Fork Release Archiveā€): https://web.archive.org/web/20241001033433/https://objects.githubusercontent.com/github-production-release-asset-2e65be/104175272/709b658d-a345-41cd-8779-edc8f067eadc?X-Amz-SignedHeaders=host&response-content-disposition=attachment%3B+filename%3Dcom.github.catfriend1.syncthingandroid_github_v1.27.12.0_9b443724.apk&response-content-type=application%2Fvnd.android.package-archive&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetproduction%2F20241001%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20241001T033433Z&X-Amz-Expires=300&X-Amz-Signature=2879adade3e95ce0cca182c3c87bb22219c5e438a31393e62dd22a7623641ff1

1.27.12.0 was what I was after, not 1.27.12.90.

Everything in the archive says fdroid on it.

2.0.3 now has a known security vulnerability, so here’s an updated version based on 2.0.8: https://github.com/marbens-arch/syncthing-android/releases/download/v2.0.8.90/com.github.catfriend1.syncthingfork_debug_v2.0.8.90_5cb7745.apk

1 Like

Hey together- I`m just a still follower of that thread because I have the same problem of slow syncing on my Poco F6 with 512Gig storage where only 100gig are free. Do massive data to sync - mostly pics and videos. With version 2.08.90 i can sync without hickups in reasonable speed. Just as another (positive) feedback. Thanks !

2 Likes

The first introduced the slowness, but the second one was reverted because I suspected that some people would install it and use it as if it were a non-test version. The second one is reverted just to avoid giving those people a known broken APK.

I’d like to see proof that commit changed anything. The first one above should be purely a refactor, it doesn’t change the caching of casefs lookups. The second one should speed things up.

I’m running 1.28.0.0 (F-Droid).

The problem is easily resolved by enabling caseSensitiveFS option for the folder in WebUI (on Android side).