leo

Also files with german umlauts (äöü) will not sync (1.4.91 on linux - ubuntu 14.4 as well asl raspbian)

Tested again with the ccurrent 1.4.44 In a WLAN without an internet connection my 3 BT-Sync Clients on Android don't see each other, they also don't see the windows instance running 1.3.109 in the same WLAN.

@GreatMarko: Tested with the 1.4.44 on Nexus 7 (2013) Android 4.4.4, Galaxy Nexus Android 4.3 and HTC Desire Android 2.2: Put > 5500 small files into one folder at the server (BT-Sync 1.4.75 on Ubuntu Linux) and synced all three clients simultaneously, watching the progress of the sync on all 3 clients in their GUI. (The most critical action in the past) Then I put a 230 MB File into the folder - also succes. All 3 "survived". The HTC is quite slow, but I think this is due to the hardware - encryption upon transfer is an expensive thing ... The GN was a little bit slow upon user feedback while transferring (maybe something else as the HTC was still resonsible) that file. But nothing crashed.

A quick check (had the new version still installed as it does not seem to crash too often), activated usage of mobile data, deactivated WLAN and after a short time some partners became visible. At the first glance: promising. ;-)

There was an update to 1.4.38 in the App-Store. Upgraded from 1.3.21 to 1.4.38 on 2 of my Android Devices. After the upgrade the devices seemed to be in sync. So I added a subfolder to one of the shares. It contained > 6000 Files with < 200 Bytes each. Both instances crashed. Restarted the frontend without any notice. Then they left the background service in a non accessible state so that the devices had to be rebooted. Another Device still on 1.3.21 seemed to work, but it came out that the sync was extremely slow - if any ... Backend 1.4.72 on Debian Linux x64 and ARM on Raspberry Pi.

@GreatMarko: But that doesn't apply to the Android Users which got the 1.4.36 by Auto-Update!

I recently tested the synchronisation on my mobile connection (synced with LAN/WLAN and didn't need it so far) The 1.3.21 as well as the 1.4.36 didn't sync with my other clients. At least not reliable. Under some rate circumstances it synchronzes - so the provider doesn't seem to block the traffic. But letting the Android client run for one day resulted in _one_ successful synchronisation that day.

No Luck here! - Shut down the ARM-Client 1.4.72 as it looks a little bit different (Clear Text Servername and no Certificate), so only the 1.4.72 x64 on Debian Linux was running. - Folders were in sync between my Nexus 7 running 1.3.21 and Linux - updated the Nexus 7 to 1.4.36 from the App-Store -> After some indexing the N7 claims all folders to be out of sync. But trying to synchronize in the Overflow-Menu of the folders told me "no files to synchronize" :-/ -> Adding a new subfolder with 750 files to the Linux-Server started synchronisation. But after a short time the Android Client froze again. Could only be killed by Settings/Apps/Kill App ... Result: Downgraded to 1.3.21 on Android.

Using BT-Sync a long time. After the currentmost version from the App-Store on Nexus 7 (2013) Android 4.4.4 and Galaxy Nexus with Android 4.3 the app became nearly unusable. (Backend by Linux x64 and ARM with version updated to 1.4.72) Both versions crash often or hang completely. E.g. while watching the folders to sync the GUI freezes or vanshes while the background service seems to continue running. Sometimes I get an ANR from Android, sometimes not. This is the first app that I have to forcefully end via the Settings/App/Force shutdown option. Just another thing: I tried to set the "Auto-Sync" Option for my folders, but that setting was forgotten serveral times until it finally was remembered ...

I sometimes connect to a WLAN without an internet-connection. I expect my Android-Clients to be able to sync when they are both connected to this WLAN, but they don't see each other there. In that WLAN there is also another Windows-Client. One Android Client does see this Windows-Client, the other doesn't. I saw this also before with the 1.3.x Versions. (Client 4.1.36 on Nexus 7 (2013), Android 4.4.4 and Galaxy Nexus, Android 4.3.)

Versions Linux x64 and ARM, connecting with Android-Clients Vers. 1.4.36 with the Certificate generated. In the peers-list I now see 3 devices with the same name - the username. The devicename is now hidden, so the devices can't be identified any more. And there should be an option to recreate the certificate e.g. when I want do adjust the user- or devicename maybe becuase of typos.

[update] Yesterday I closed BTSync on my Android-Devices. Today I had do restart my Galaxy Nexus due to problems with the Internet-Connection. Tested BTSync again. Now the Galaxy Nexus is recognized by name also with my RPi device. And my synchronisation test exactly like above now worked as expected ... ... strange ... :-/

Just to make shure: You shared one folder on device A and entered the secret generated by device A as secret for that shared folder on decive B? [Edit] OK - then this is not the cause ... never mind ...

My feeling is that BTSync has a problem with fast updating files. Updates (and/or) removals while synchronizing may be the problem ...

I now seem to have this problem with another folder and another set of clients. I share a folder between my Win7 client and my Netboox (Win XP) - contents is the Calibre Library. I updated the Library with Calibre - while the Netbook was online. He synced the files while I was working. Then I closed Calibre. But the sync won't finish. I have 2.1 KB that won't be synced. How to determine what is blocking there?