RomanZ

liveoutloud, Few things to check: 1. Check hidden files. I guess some of data might be stored in .SyncArchive 2. Check the UI (devices tab) - it usually shows amount of data to be synced as well as has a black "i" symbol which can show you which files to be synced yet.

nesreb, First step - make sure that both your laptop and RPI time is synced with some NTP server, (I guess laptop is running ahead of RPI). If it does not help - i'd gladly hunt down this issue if you grab a debug logs from both RPI and your laptop. Set log_size to 100 to ensure issue will get into the log.

Ole, Files are moved to .SyncArchive only when they are modified by BTSync, not by user. So, when you edit your files on Win8, all other peers will store files in .SyncArchive, but not Windows. If you will delete some files on Linux server, BTSync on Win8 machine will move appropriate files to .SyncArchive.

zucrapoc, If you are using Android 4.4 - BTSync is forced to sync only its "home" folder by OS. If this is earlier version of Android - you can tell BTSync to sync your DCIM folder.

@patoka, 1. Need debugs, from both peers. 2. Thanks for reporting, we'll check why it happens and how it can be fixed. 3. Well, pretty strange - but not deadly. In 1.3 BTSync finds tracker and relay server by downloading http://config.usyncapp.com/sync.conf, so until config.usyncapp.com DNS name resolved succesfully - it is okay. @pmafli, We are aware of the issue. As a workaround you can try to add these xattrs to syncignore.

It's not abandoned, but rather postponed due to more urgent demands. It's still in our queue. Sorry, can't share ETA for now.

Ethan, Could you please elaborate? Which "Download icon" do you mean? Which OS refuses to start BTSync automatically? As for the second request - AFAIR there is such proposal in the wishlist. suntear, Let's take a closer look at your Android logs to see what is happening. When you come home and restart your Android - tap a feedback after it fails to see Win machines, agree to send logs.

Of course. OSX has another API to access xattrs. We'll consider it in future. Not sure that I understand what you ask. If file system would be NTFS - BTSync will put synced xattrs to alt streams as was designed.

vtarry, It's simple enough. - Store your secrets somewhere. - Remove all folders hosting on your ext drive so BTSync removes it's service data. - Connect your ext drive to new Mac - Add folders using previously stored secrets.

knireis, Is this something new or you experience the same issue before? If this is new issue - what is the previous build you were using which had no issue?

ubik, The fact that your BTSync does not see other device usually means some connectivity issues. Could you please describe your environment? Is your second device located in the same LAN or across internet? What is the OS on another device? How both of them are connected to internet?

okibcn, My first suggestion would be to run ProcessMonitor tool on your Site B, set the filter to one of these mysterious files and see if indeed no other process access them. BTSync will add a message on modified file in history when it's mtime gets changed, so even if some app "touch"-ed the file that would be enough to generate the "Updated file xxxx" message.

viktorct, I also consider trying to access webui with a different browser (or cleaning up cookies). Also - could you please let me know the amount of folders and files in sync folders on RPI device?

Konstantin, Thanks a lot for such impressive issue analysis! Let me check how quickly the issue can be fixed with development.

Jack Nihil, Debug logs would be wonderful. Alternatively - if you'll find any scenario for stable reproduction, we can try to reproduce it in lab or explore code to find a culprit.

JSommer - please see my response in other topic

smeerbartje, I don't think that data gets corrupt while transferred over network: almost every network layer is protected with bunch of error detection codes. Most possible scenario - if some app is actively working on the file which is being transferred.

justlikekevin, Couple of things to check: 1. Make sure that your iOS device is connected to either LAN where your Linux Mint sits, or has live connection to internet. 2. Make sure that BTSync is active application on iOS as it won't sync in a background due to iOS limitations. 3. If you are on LAN - make sure that your Mint machine has LAN discovery turned on in BTSync folder properties 4. If you try to sync over Internet - make sure that Mint machine has tracker server enabled in BTSync folder properties, also make sure that TCP/UDP outgoing port 3000 is enabled on your router. 5. If your Linux PC has several NICs - try disabling all of them except one (there might be an issue with discovery of BTSync in LAN if PC has multiple network interfaces) Most likely it is some connectivity issue, as you don't see your iOS in devices list on Mint PC. If all of the above does not help - I'll need debug logs from both iOS and Linux PC. For iOS - just send a feedback (app need to be up and running trying to contact your Linux for several minutes) and agree to send logs, plus put a link to the forum topic in feedback form). For Linux - instructions are here.

Kampfmelone, Thanks for reminding. For now we do not support x86 CPUs in mobile phones, only ARM. We would like to add it in future, but I can't share ETA for now.

Dantounet, This setup is feasible and indeed achieved by adding a plain sync folder on Android device (a folder with photos) and adding it on, say, your Mac. It should work fine in 1.3 Do I understand correctly that it was working on some previous version? If yes - which one? Also, are you using auto-sleep option on your Android device? If yes - you should give your Android phone a time to check for changes and sync them to Mac (time depends on your Sleep value).

bigbertha, Are your seedbox and Mac located in the same LAN or they connect over internet? If they are in LAN - I consider installing 1.3.87. If they connect over internet - make sure that your NAT (airport extreme, as you mentioned) either maps your port 11411 to your device OR supports PMP.

Suntear, The local discovery mechanism has changed in 1.3 to reduce amount of generated service traffic in LAN. Let's try to find the answer in debug log. Please turn it on for PC (it is always on for Android device) and once issue reproduces - collect both logs on PC and on Android (on android it's enough to send feedback and agree to send logs, note the forum link in feedback form).

Richard, It depends on how your MiFi device behaves. If you try to connect both devices to a single MiFi and they do not "see" each other in devices list - I consider checking MiFi's settings if it routes packets to other devices connected to it, or only to internet. If you try to connect a single device to MiFi and it does not see the rest of your peers over internet - make sure that device allows to pass TCP/UDP port 3000 and supports UPnP / PMP.

krtaylor, Thanks, we'll do our best to find out the root cause.

klausemann, This setup should work. Please check several things: 1. What kind of files NASes are syncing between them? Please check that when the file is updated, it changes either the size or mtime. 2. Doesn't files sync after 10-20 minutes? It might happen that NAS OS did not notify BTSync on files changed, so changes will only be reflected after full folder rescan. 3. The existing files - who is the owner and what are the permissions? Make sure that user running btsync is the owner and has enough permissions to read and write these files. If all above does not help - I'll need 2 debug logs, from 2 of your NASes, set log_size to 100 on both to make sure issue gets into the log. Remove all the nested folders from NASes (i.e. make sure that only 2 of them see each other). Modify some file on NAS, make sure it is NOT propagated to other NAS after 10-15 mins. Collect the logs and send to me - I'll try to find out what is happening between your NASes.