Photos added from Camera app take longer than manually added files

Support
1

Hi all,

I noticed something weird: Basically, manually copying a file into my DCIM/Camera folder on my phone results in a much faster sync to my laptop than if I take a photo with the camera app, which also places the picture into DCIM/Camera. (I made sure that the test files which I manually copied into DCIM/Camera are always new, i.e. syncthing has not seen/hashed them before.)

I tested this on a Pixel 8 and also a Pixel 5. On both phones, I tested this with the stock Camera app from GrapheneOS and OpenCamera from F-Droid.

My general setup

  • Linux laptop running syncthing 1.29.3
    • In advanced syncthing settings, set fsWatcherDelayS to 0.5.
  • Phone (Pixel 8) with GrapheneOS (currently Android 15) running syncthing-fork 1.29.4 (from F-Droid)
    • In advanced syncthing settings, set fsWatcherDelayS to 1.
  • Phone (Pixel 5) with GrapheneOS (currently Android 14) running syncthing-fork 1.29.4 (from F-Droid)
    • In advanced syncthing settings, set fsWatcherDelayS to 1.
  • Syncthing only runs over LAN via local discovery (no global discovery, no NAT, no relaying).
  • Each phone has their DCIM folder shared with the laptop, so no loops in the sync graph.

For the following, by “full folder” I mean a folder that contains 800 photos (3.8 GB) and 200 videos (8.3 GB), so a total of 1000 files (12.1 GB). By “empty folder”, I mean a folder that contains about 10 photos à 5 MB.

I did use the same dataset of photos and videos for both phones, for consistency.

Measurements on Pixel 8

  • New photo with Stock Camera into “full folder”: 45s-48s
  • New photo with OpenCamera into “full folder”: 15s
  • New photo with Stock Camera into “empty folder”: 1s
  • New photo with OpenCamera into “empty folder”: 1s
  • Manually copy a file into “full folder”: 1s
  • Manually copy a file into “empty folder”: 1s

Measurements on Pixel 5

  • New photo with Stock Camera into “full folder”: 4s
  • New photo with OpenCamera into “full folder”: 5s
  • New photo with Stock Camera into “empty folder”: 1s
  • New photo with OpenCamera into “empty folder”: 1s
  • Manually copy a file into “full folder”: 1s
  • Manually copy a file into “empty folder”: 1s

Additional info

I measured the time just by looking at the clock, while having something like watch -n .1 'ls -lat pixel8_DCIM_sync/Camera | head -n 10' running on my laptop. I did several measurements, on different days, and rebooted the phone inbetween.

On all cases where the time was above 1 second, there was a temporary syncthing file present, e.g. .syncthing.IMG_20250505_001914_896.jpg.tmp, which was then renamed to e.g. IMG_20250505_001914_896.jpg when the sync finished (that’s when I noted the time).

I’m aware of syncthing’s slow performance on folders that contain many files, but it seems that this issue here is different.

My question

I would be interested if someone could think of an explanation of this issue? And maybe even has ideas for a fix, or how one could debug this further? Maybe someone could try to reproduce this on another phone?

Semi-related: Over the course of these tests, I renamed DCIM/Camera to DCIM/OpenCamera and DCIM/OpenCamera to DCIM/Camera (using one temporary name to avoid a collision). After that, I had to restart syncthing-fork for it to recognize new photos again, for some reason (even though I did a manual rescan and waited until both devices were in sync again).

Thank you :slight_smile:

2

This is a different problem. Basically, the file watcher is tied to the original folder, and it will keep tracking changes in it even after renaming or moving it to a different location. Only a full Syncthing restart fixes the problem, changing the watched folder to the new one. I think there should be an issue on GitHub open about this (but I’m not 100% sure).

3

I think I found the issue: fsnotify: fs events have wrong paths after renaming a directory, then back to original name · Issue #7950 · syncthing/syncthing · GitHub

Good to know it’s a known issue.

4

Is it inappropriate if I create a Github issue about this, in case there are no more replies/solutions in, say, 1-2 weeks?

Also for transparency I crossposted this on the GrapheneOS forums: Syncthing issue: Photos taken with GOS camera app take much longer to sync - GrapheneOS Discussion Forum

5

Honestly, you could try creating an issue, but I doubt there will be any quick fixes for this soon. The problem doesn’t seem to be about the Android app but rather Syncthing proper, and specifically related to how the file watcher integrates with the Android OS. You would need someone, who is knowledgeable about both, to investigate and find the culprit. At this point, we don’t even know if this is a problem that can be fixed on the Syncthing side, as I feel that there may be something more going on when image files are generated and saved by those Camera applications in comparison to just placing them in the folder manually…

1 Like
6

For comparison, I ran a similar test with my Android 14 (Motorola) phone…

With the default fsWatcherDelayS=10, a new photo taken with either the stock camera app or OpenCamera (internal and SD card storage) synced from my phone to my Linux server in just a tad over 11 seconds (eyeballed it on a stopwatch, so plus/minus fractions of a second). Same amount of time compared to manually adding image files. It didn’t make a difference whether there were existing photos or not.

(When I have a chance, I can repeat the test on my Pixel 4 and also try increasing the number of photos since I don’t normally keep more than a couple hundred at a time.)