RomanZ

@mt104 No, it's not firewall related. Let's collect debug logs and see what is inside. Please send them to syncapp@bittorrent.com, refer to this topic in your message.

@suhrim Try stopping all instances and run a new one from console, like: killall btsync./btsync --no-daemon --config <config_path_and_filename>

Your voice counted. Moving topic to Feature Requests.

Hi, Actually it should be idle when nothing happens. I can only suggest 2 things: 1. Some other app is constantly touching files - so Sync has to process OS notifications about files that might get changed 2. Due to numerous amount of files if indexes files all the time (@petromycon - not your case as your rescan interval is 1 day). I can be more precise if you send me debug logs to syncapp@bittorrent.com (refer to this forum topic plz).

@oldschoola Both "folder_rescan_interval" and "sync_trash_ttl" are advanced preferences - and are not available in Linux GUI. They can be configured only via config file on Linux PC. .SyncArchive is a hidden folder. Try looking for it from terminal window with "ls -al" command or just enable showing hidden files in your shell.

@suhrim Your API key is okay and is not blocked. Even more, your config file started in my lab with almost no changes (have to adjust storage path). Aren't you using any proxy / firewall that might change / corrupt the traffic? Also, which platform do you run API?

@mrspcs You may also use API. As for the logs - if you enable debug logs, it will contain excessive information about who connects and which files were downloaded.

@mt104 Unless any of your nodes is using port 1900 (which I doubt) as "Listening port" it should be fine. BTSync usually uses mulitcast over port 3838 in LAN and direct TCP/UDP connections to random pre-configured port. Make sure that they are not blocked by FW - and traffic must flow

@simondarren Some short question: Do you know if files on machine B were changed / modified after "BTSync Stopped working"?

@EricRF When you see BTSync talking to some unknown IP addresses indicates that it communicates DHT network. Also, if you turn it on once for even a while - DHT network will remember your IP:port and still send some packets to you. I suggest checking that DHT is off for all folders and changing listening port so DHT can't contact your peer anymore.

Hi AntonK. Unfortunately BTSync for Android does not support Intel CPUs. Only ARM.

@kcant1 Do you have any other application that might work actively with the files in sync folders? It might reveal the issue why files are gone (all the apps are very different on how they actually work with the file).

Hi all, We would like to reproduce the issue in our lab. Could you please share more information? Which "older" version consumed less CPU? 1.3.94? 1.3.50? 1.2.82?

@edc BTSync has some issues working on systems with multiple NICs active. If your cable LAN and wireless have different subnets - adding predefined hosts should work just fine.

@splendid2k Fix is implemented in upcoming 1.4 release.

@werham Where your Sync folders are located? Internal / external SD? Internal memory? Usually, when you set up a Selective (non-automaic) sync folder on Android device - the folder structure gets created automatically after first contacting to the remote peer(s). I suggest re-adding folder and checking if folder structure is created as it should.

@thavidu I don't have precise estimation on my table, sorry - but pretty soon. Say, Summer 2014.

@lkjnhbgv You can adjust your "sync_trash_ttl" setting on the PC. By default it orders BTSync to delete files after 30 days being in SyncArchive. If you set it to "0" they will be never deleted.

@paraeldani BTSync will support proxy soon.

@b0rman Also, if your files have wrong file date/time (for example, below epoch time or files from future) - it also might cause problems (starting from simple "not syncing" and to crashes in certain cases).

@zbigb69 It is possible if your run BTSync with /config parameter. In this case you can explicitly set the path to store to any designated location. Another option (to be precise - a hack) is to adjust environment variables. BTSync uses %appdata% variable to find location to store its files. As you might know, env vars are inherited from parent process, but actually every process keeps its own copy of env vars. So, if you make a batch file which sets the %appdata% env var to some different location and THEN launches BTSync, BTSync will have a different location for appdata - and will load / save data there. However, I did not test it in the lab - so please use with care, might have some side effects.

@frater Are both boxes Linux? If one of them is Win/Mac you can take a look which files are queued to sync by pressing the black "i" button in the devices list.

@BeTheSync I guess that would be the most straightforward way: use a scheduled shellscript to run BTSync with 2 different config files depending on time. You can use built-in iCal to schedule a job or use any 3rd party utility to do so.

@suhrim Great, thanks. We'll take a look what could be wrong with your config or your API key.

@oldschoola 1. On desktop clients there is no schedule. If BTSync is running, it will receive OS notifications on file changes in sync folders, and approximately around 15 seconds after changes is done - it will start syncing files. If OS does not send notifications (for example, you have excessive amount of folders or really deep folder), BTSync will detect new files every folder_rescan_interval (which is 10 minutes by default and can be changed in advanced preferences. On Android device it is slightly different. BTSync core goes to sleep when no actual transfer occurs to save device power. It will wake up every period (30 mins by default) to check if any new data is available on Android device or on remote peers to sync. The sleep mode can be disabled or the sleep period adjusted. 2. Yes, you can pre-copy files to avoid extra file copy over network. BTSync won't re-sync already existing files. Please note, when copying share manually - DO NOT copy BTSync service files (like, .syncID, .SyncArchive, etc), as it is going to break Sync logic. 3. "Wifi only" - yes, you can do it. Disable the "Mobile internet" in BTSync options to force BTSync sync data only when it is in wifi range. Unfortunately, BTSync does not support schedule yet. 4. You can do it. All the files deleted on one peer are moved to ".SyncArchive" hidden folder on another peer. They stay in archive for 30 days by default. All you need to do on your archive peer is to change the "sync_trash_ttl" advanced setting from 30 to 0. In this case your deleted pics will never be deleted from .SyncArchive.