greentown

Jimmy, your analyses are very interesting. I had high hopes for the battery issues with 1.1.48, however your findings are disappointing. I'd be very interested to know of any updates with, hopefully, better news.

I've read similar stories in the forum. I would suggest that you "help" it a bit: Stop btsync in one of the computers with fast connection. Synchronise from your slow computer to it. Once some files are completed uploading, stop btsync in your computer and start it in the one where you stopped it before. This way, there is only 2 computers with btsync running at the same time and they will be forced to sync with each other. I know it's not the way it should be...but it should get you going at least to make the initial sync.

I don't have such a complex setup and thus I haven't experienced those problems. But if what you're explaining is the current behaviour of btsync (and not some kind of bug due to your settings or similar): WOW, what a disappointment. From a user perspective you expect btsync to do a correct synchronisation, so new files should overwrite files with the same name if they are older.

The answer to your original question is yes. As for Greho, I don't really understand why he makes that question though...how can a slave override what the master dictates, it's simply out of the question. BTSync will make sure that there is coherence between shared folders among all peers, so you don't need to worry about the slaves misbehaving, because they won't.

Hi, I posted a related thread here, but this post is about looking at the problem from a different angle. I have a linux machine with read-only secrets synchronising with a Windows machine. When the Windows machine is off, the linux machine should basically do nothing, since it is a read only client. However, every 30 minutes my HDD is woken up. Since it is a read-only share and no file can have changed, why does btsync wake up my hard disk? Best regards, Greentown

I created this topic: http://forum.bittorrent.com/topic/22318-bittorrent-sync-and-disk-spin-down/#entry62044 And I was seeing the same behaviour as you. What I didn't know is that the 30 minutes period was for reading the settings.dat file (and not rescaning the shared folders, as I thought). In my case I could move it to the sd card, but I still think that the application is not working as it should.

I created a similar topic some time ago: http://forum.bittorrent.com/topic/22318-bittorrent-sync-and-disk-spin-down/#entry62044 ...but never got a helpful answer. In my case, I saw HDD activity every 30 minutes, not 10, but I think you have the same problem as me. It's a pity, because this way BTSync is not very enviromentally friendly...

If you're getting those logs, you've clearly not unblocked it (yet). You almost have it!

I haven't used ufw myself, but I think that you should turn logging on and see what's being blocked by the firewall. Then you'll just have to allow that kind of traffic.

Let's say that it's not best practice. To run it as another user, first you will have to change the ownership of everything under your .sync folder to the new user you would use. Then, you just login as another user, for example "pi" and run it. OTOH, since you're asking these question it may be easier for you to get it from a repository, which will take care of most of your issues. Have a look: http://forum.bittorrent.com/topic/18974-debian-and-ubuntu-server-packages-for-bittorrent-sync/

Very good read. I haven't done such detailed tests, but your findings are in line with my experience using btsync for android: it used WAY too much battery, even when idling. I guess that being a beta, you can't ask for more. From what I've seen in other android apps, making a battery efficient application doesn't seem trivial at all. More so when the application has to periodically monitor a local folder for changes or to contact other systems in order to see if something has changed in the other side. I guess they still need to work a lot on it. In the meantime, I think that maybe they could give the android app some options to tweak those parameters and allow us to make the app a bit more battery friendly.

Hi, As far as I know, if you mark the "Search LAN" option, it should work on a LAN, using multicast, without any access to the internet. Judging by your firewall rules, multicast should already be allowed. Do you have all devices in the same LAN or is there a router in between? Do you have several network interfaces in your rpi? Also have a look at this, it may help: http://forum.bittorrent.com/topic/20144-local-lan-discovery-sends-multicast-out-eth0/ Good luck

Hi, I tried your suggestion and removed the space, but I still get the same behaviour: date: 2013-08-01, time: 13:19:50, disk: sda, running: 992, stopped: 810 date: 2013-08-01, time: 13:49:52, disk: sda, running: 902, stopped: 900 Yes, I am restarting the daemon each time.

+1 from me too

Hi, I have a problem with btsync triggering my external usb disk to spin up when there is no transfers going on. I'm using BitTorrent Sync to sync some folders that usually don't change much. I'm running it on a Raspberry pi, Windows and Android. Since the Raspberry pi doesn't consume much power, I leave it on all of the time. However, since there are some days in which the content of the folders don't change at all, I am very interested in getting the USB hard disk connected to the pi to spin-down. The spinning-down works well, I am using a tiny program called hd-idle. The problem is that btsync seems to spin-up the disks every half an hour... This is an extract of the logs from hd-idle: date: 2013-07-31, time: 16:30:57, disk: sda, running: 901, stopped: 900 date: 2013-07-31, time: 17:01:00, disk: sda, running: 903, stopped: 900 date: 2013-07-31, time: 17:31:07, disk: sda, running: 907, stopped: 900 date: 2013-07-31, time: 18:01:14, disk: sda, running: 907, stopped: 900 date: 2013-07-31, time: 18:31:21, disk: sda, running: 907, stopped: 900 date: 2013-07-31, time: 19:01:30, disk: sda, running: 908, stopped: 901 date: 2013-07-31, time: 19:31:36, disk: sda, running: 906, stopped: 900 As you can see, the disk is spinning ("running" in the logs) for around 900 seconds. As per the configuration, the disk is spun down after 900 seconds idle, but it only remains so for 900 seconds, when it's awaken by an application. If I stop btsync this behaviour also stops, and the disk sleeps much much longer, so I know that btsync is causing this. I've tried changing some setting in the config file, specifically I've added the "advanced" option "folder_rescan_interval" : 86400, but it has not changed anything. Any ideas to keep btsync from from spinning up my disk every 30 minutes?