Syncthing-android: "WiFi only" should not depend on "background/foreground", Wifi only should be default

Created on 27 Jan 2016  Â·  25Comments  Â·  Source: syncthing/syncthing-android

've been an early adopter of btsync and used it for a long time. When things became sour there I started investigating syncthing and watched if I could use it as an alternative.

After successfully running it for a while on both Linux (in datacentre) and Windows I started my first experiment on Android.

I had some trouble loading the sync as I expected "the sync" to be pushed to my Android just like on the other devices. When I did get it to work it immediately started sending all the data that was in the sync I was testing with.

I wasn't prepared that this could happen as all syncing software on mobile devices I've used thus far are made in a way that syncs are by default "on demand".
Now I know this hasn't been implemented (yet??).
This makes it useless for all my real world scenarios I have currently working with other software.

But my bad luck didn't stop there.
Whilst syncing I got a message that my dataplan was running out and before I could stop syncthing it burned 2.6 GB of the 3 GB dataplan.
I had my WiFi turned off because I travelled that morning by train which always gives me a bad WiFi-connection.

Some said I should have turned "WiFi only" off, but at this stage I was still running it as a foreground application. That option is not selectable then,,,,

IMHO the WiFi-only should be the initial setting and this should not depend on ""foreground/background"

I've removed the application for the time being, but I will install it immediately whenever an "on demand" is implemented.

Remark:

If "on demand" would be possible (and turned on by default) it would make sense to couple it with foreground/background. Now it doesn't (as I found out).
I would have rather paid the € 10,- to you instead of T-Mobile.

enhancement frozen-due-to-age

Most helpful comment

@fraternl Help is on the way ...

All 25 comments

At the moment, the way we disable Syncthing is by shutting down the binary. This means the GUI is unusable at that time. We can probably change this now that Syncthing supports pausing devices.

See #81 regarding selective download.

It would definitely be an improvement. Still the current behavior has the advantage that while sync is not running, the binary is not running and doesn't require resources.

Pausing devices also has the disadvantage that it only works while Syncthing is running. After a restart, it will be unpaused again. By the time we can pause it through the API, it might have already connected to other devices (and transfered data with them).

Maybe a command line option in Syncthing to always start paused would solve this.

I think there is one already

You're right, there's syncthing -paused. Now someone just needs to implement this all :D

I don't know why the title has changed, but I chose that title to indicate exactly what is wrong....

As a first-time user I will not have it set to run in the background and therefore I can't select the WiFi-only. I don't see why there has to be a link between these 2

implementation should follow usage not the other way around.

@fraternl while I mostly agree with you, as a first-time user you won't have any sharing configured (yet) and therefore this won't cause much traffic over your mobile connection (basically only discovery service).

I was a first-time user of the Android app... not the desktop version. There are several months between my first usage of syncthing and the syncthing Android app.

Even if you are a first time user of the Android-app it is even more than likely you will have it setup on a desktop first.

Still you first need to add the devices and shares, so you are not right away using data. In my opinion we should change the notification for the running service (connection status) to default-on, not hidden like it is at the moment.

You are just repeating what you said before and assume others are doing things exactly like you

As I said...
I have many btsync shares running for others. I have several syncthing shares running for me personally. Among 1 with a 5 GB music collection.
This is experimental. I'm researching syncthing to see if I can shift my clients to syncthing

A month ago I wanted to use syncthing on my Android instead of btsync and used that music collection for this. I now know the Android-app is useless for my applications, so I removed it until "on-demand" is implemented.

I fail to see the logic between WiFi only and background/foreground...

To shift my clients from btsync to syncthing I need at least 2 features implemented.
That's "on-demand" and "share notification"
The first one is a show stopper... the 2nd one would be nice

"WiFi only" checkbox should be completely unrelated to everything else, just like any other application. It does not matter whether Syncthing is in foreground or not. Or whether user triggered sync manually. If "WiFi only" enabled, it must not communicate over any network except WiFi. If user wants to use mobile networks, he can uncheck the option.

As I said, I completely agree with you. But unfortunately the way Syncthing on Android is realized at the moment, that cannot be easily done at the moment. That's what @Nutomic and I were trying to explain.

OK... that part wasn't clear to me..

There should be no need to say these things and implying that this is not that important or "does not happen that often". That's just clutter.

@fraternl Sorry, I found the title confusing and tried to clarify it. I changed it back now, so it's (hopefully) clearer and also correct.

Just weighing in with my case:

  • Synching music. Had "background" and "only on wifi" checked.
  • A few weeks later I decide to uncheck "background" because I wanted to check if this was causing a recent battery-draining-issue.
  • I did not review the settings closely after unchecking.
  • Falsely assumed "only on wifi" was still on: I remember switching this on, not switching it off.
  • Gone out of the door one day, forgetting to actively close Syncthing.
  • 3Gb bandwidth dataplan for February was consumed on 4th of February already. 24 more days to go.

In my case, reviewing the settings closely revealed that unchecking "background" would disable "only on wifi" since these settings are grouped. But this is not how most apps work, nor is it made abundantly clear that unchecking one, will uncheck the other too.

+1 for this feature request

I also accidentally burned through my entire data plan in 1 day. Syncthing is removed from my android phone for now. I will come back when this is implemented, preferably with an option to override per folder.

Thanks people, 0.13 seems to support this!

This bit me also. I prefer not having Syncthing run in the background, as it can be a bit of a battery hog if there's a lot of data. I can easily start Syncthing whenever I need it to sync things. But I also lost quite a bit of money because apparently my phone randomly decided to disconnect from a wifi network even though the wifi was working just fine, and I had Syncthing running a full sync of my 50GB music library to a new computer at the time.

As a workaround: you could disable cellular data usage in the Android settings for the app.

So, I can disable Background data usage. But that's not necessarily the same thing as all cellular usage, right? If my app is in the foreground (because I originally had background running disabled, so I only ran Syncthing as a foreground app when I wanted to actively sync), then the app will continue to churn through my data merrily while running in the foreground.

Frankly, I would agree that it's relatively astonishing that Android itself doesn't support this use case natively. But most apps that deal with large data do offer it themselves as a non-dependent toggle.

@petergaultney Oh, you are right. On my LineageOS I had the possibility to disable cellular in general, not only background. Was not aware that this was not a stock option, but see it is not available on my Moto G6+. Sorry. So this is _not_ a valid workaround.

@fraternl Help is on the way ...

thank you, @Catfriend1 !

Was this page helpful?
0 / 5 - 0 ratings

Related issues

scienmind picture scienmind  Â·  6Comments

voidcase picture voidcase  Â·  3Comments

reverse-unina picture reverse-unina  Â·  3Comments

klausenbusk picture klausenbusk  Â·  9Comments

denis-yanko picture denis-yanko  Â·  5Comments