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?

Updated all clients to the current version (1.1.42 / 1.1.19) Same behaviour as before. Still the Galaxy Nexus writes back the old version into the system. Uninstall / Reinstall and newly adding the folders doesn't change anything. What I can observe is that in the file-view the correct file is indicated. (The new version is remotely indicated with a progress bar of 0%) Upon copy I can see the correct file-length on the local side (as indicated by BTSync), but when I take a look into the filesystem, there is the old version. And then this version gets synced back. At the same time the Nexus 7 - same Version of BTSync and Android behaves correct. :-/ What is strange is that all other clients show the Galaxy Nexus as in sync whereas my RPi shows the Galaxy Nexus heavily out of sync. Also the Device Name is not recognised by the RPi (shows only the IP and Port) whereas the other clients show the correct name and timely follow the changes of the name on the Galaxy Nexus ... Something seems to be broken on the Galaxy Nexus ... but how to correct?

Updated all clients to the current version (1.1.42 / 1.1.19). To do so I first shut down all clients, then updated and restarted the clients. - The Zombie-File still existed - on the Android-Client it was existent before. Showed the progress bar (with 0% progress) and nothing more happened. - Uninstall / reinstall didn't change anything. So I opened the corresponding .ods file again on Win 7. This created a new lockfile that was named exactly like the zombie file. This file synced to all clients (including this one). Then I closed the file, the lockfile was deleted and removed from the clients. No zombie file visible on the Android-Client any more. -> See my post regarding the syncronisation errors. There still is a problem.

With 1.1.19 all my folders were visible again. Only updated the client. No uninstall / reinstall necessary.

1.1.42 seems to have fixed the crashes. Restarted computer. updated client and started BTSync. Client synced OK. Started a chat on Win7 with Trillian. Changed log-files were transferred. Here 1.1.40 crashed on XP. Now they were synced. Also opened Thunderbird on Win7. While working there the changed files were synced without problems to XP. So I think this bug is fixed.

In one of the folders I share with some devices there seems to be a zombie file. The android client shows a file on the remote side of a folder, that is not existent (any more). It has the progress bar below the filename but nothing is transferred (OK, because no other client has this file any more). But all clients state that this folder is completely in sync. It was a lock file from open office that was generated for a short time when I opened the corresponding file. This only for a short time so that the file might be deleted while being synced? The corresponding file was deleted, and vanished from the list of files, but this lock file remained. (All clients run the latest versions of BTSync: 1.1.40 on Win7, WinXP SP3, Vista and ARM (RPi) and 1.1.17 on Android) (In order to detect more of these files it might be helpful to see a list of files for each folder shared together with the syncstate of every file)

Well ... The computer that holds the source of this data was: Win7 64 Bit SP 1 with constant updates The client that crashes (an old Asis Eee PC 1000h: Win XP Home SP3 also patched to the current level, Both computers run BTSync 1.1.40 Yesterday I put the Eee-PC (that one that crashed) into hibernation. Now I restastarted it and it tried to resync. Now it crashes again. I can see that it is synchronizing the thunderbird-cache (still thinking about if it is a smart idea, but it worked in my previous scenario) without thunderbird being open at both computers. (Yesterday eventing I started thunderbird so the changes are OK) After 4 crashes (I always answered to send the dump to the developers and the application restarted) In the History on the Win7 computer I can see that the XP-Computer sent 4 files out of the Thunderbird cache back to the Win7 computer. Why? The XP Computer wasn't switched on and also Thunderbird not started on that computer. So a back-transfer is not to be expected! Now after 4 crashes, sendig dumps to the developers and restarting the app, BTSync states to be in sync again. (Also no activity on the hard-drive, so one can expect that this is the truth)

Maybe it is somewhere here in the thread: - An indicator on the tray-icon (or notification icon on Android) that indicates the state of the application: In sync / ouf of sync of all folders Currently transferring or not So one can easily see if it is safe to go offline with a mobile device or not. - An option to see which _files_ in which folders are out of sync. e.g. as sometimes there are folders that won't get in sync because some client has a file open. The Android-Client has some sort of that functionallity but it would be nice to also see - Also list the files in sync together with the corresponding timestamp (and filesize) so one can easily verify that the correct version of a file has arrived. - Make the device tab sortable. (sometimes it is interesting to sort by device, sometimes by folder ...)

... and another (strange) one: I updated my both Android Clients from 1.1.16 to 1.1.17 On the Nexus 7 no problems. On the Galaxy Nexus I now can only see 2 of the 4 folders I sync. The other clients correclty list the Galaxiy Nexus online for those folders and the content gets synced.. If I try to add the folders I can't see, they BTSync claims that they are alreaydy added. OK, as they are actively synchronizing. Uninstall and reinstall does not change the situation. If I add those 2 folders, they are added, but are hidden in the list of folders. (One of those folders is synced with my Nexus 7 and there it is visible so it is no generic android problem for those folders.

I use Trillian for chatting. The log directories of Trilliian are synced by BTSync. When I started a Chat on my Win7-Client the Win XP-Client crashes after downloading the changed log-file from Trillian. I let btsync send the dump file. BTSync restarted and crashed again. This until I closed the chat. Seems that I can reproduce the behaviour: I again started a chat with Trillian on the Win7 computer and the XP client crashed after it has downloaded the changed log file.

Updated my Clients to 1.1.40 / 1.1.17 (Android) Still the same problems: Added a text file without content (zero bytes) on the win 7 client. -> Nothing was synced. OK, one might say that zero bytes don't have to be synchronized, but sometimes the existence of a file matters regardless the content. Now I updated the file (one byte ;-) ) and saved. Now the file was synced. Waited until all (all of the one mentioned above) devices were in sync again. The file was copyied to all clients as expected. Now I changed the file on the Win7 Client Change was detected and all clients were out of sync. The file was correctly synced with th XP client. Then the Galaxy Nexus claimed to have updated the file and wrote back the old version. :-( This file was then synced to all the other clients, including the Win7 client and overwriting my change.