Jack Nihil

I think I have a similar issue. There is a folder propagating amongst my btsync nodes with the names 'audio' and 'Audio' with exact same contents. I believe this is also Windows not differentiating the case of directory names, but Linux does. Coupled with the fact that btsync seem to not be able to deal with multiple hosts with r/w capability and hence I end up with syncing files back which were deleted already on another host (see post http://forum.bittorrent.com/topic/28288-reference-node-master-nodes-fighting-with-each-other/ ), btsync isn't as useful as I thought it would be. I think I'll revert to using rsync or try out Seafile/OwnCloud.

For the most part the multicast-to-unicast conversion works well - multicast is sent out at a low data-rate, consuming much air-time and low-throughput. Unicast conversion allows for a high-data-rate transfer to the client. However, some apps do not like this behavior. btsync must be one of them.

Thank you RomanZ, your comments on multicasts made me investigate the Wireless Access Point I use. This AP has a feature called directed-multicasts, whereby it converts multicast packets to unicasts to achieve a higher data-rate on the air. I disabled this feature and... BHAM! The Droids and the Linux hosts are one happy, synchronized family. Thanks for your help and patience. Best Regards.

Hi RomanZ, I had some time to investigate this issue today. Setup: Android 4.1.2/btsync 1.3.21.0 - IP:192.168.1.150 Ubuntu Linux 13.10 (kernel 3.8.0.31-lowtency)/btsync 1.3.94 - IP:192.168.1.111 This is the sequence of events, together with the sync.log from Linux. I took the liberty of removing some info which looked 'private'. 1. At the beginning, I pause/un-pause bysync on Linux and then both devices sync: [20140510 19:00:19.101] ping 192.168.1.150:58347 [20140510 19:00:19.101] Checking connection to 192.168.1.150:58347:TCP [20140510 19:00:19.102] Checking connection to 192.168.1.150:58347:uTP [20140510 19:00:19.102] Sending broadcast ping for 5 shares [20140510 19:00:19.102] Failed to open tunnel to 192.168.1.150:58347:TCP [20140510 19:00:19.377] Got tunnel to 192.168.1.150:58347:uTP, total tunnels: 1 [20140510 19:00:19.377] Best tunnel now is 192.168.1.150:58347:uTP [20140510 19:00:19.880] Incoming connection from 192.168.1.150:58347 [20140510 19:00:19.883] Incoming connection from 192.168.1.150:58347 [20140510 19:00:20.000] Got id message from peer jnihil SC-06D 1.3.98 . . etc . [20140510 19:02:12.147] SyncFolderNotify: ".SyncID", event = "IN_CLOSE_WRITE" [20140510 19:02:12.147] [OnNotifyFileChange] /home/jnihil/phone/.SyncID, source = NULL Syncs. So far looks good. 2. The Android leaves the network: [20140510 19:03:21.894] Lost tunnel to 192.168.1.150:34735:TCP [20140510 19:03:22.241] ping 192.168.1.150:58347 [20140510 19:03:22.241] Checking connection to 192.168.1.150:58347:TCP [20140510 19:03:22.241] Failed to open tunnel to 192.168.1.150:58347:TCP . . etc . [20140510 19:04:22.138] ping 192.168.1.150:58347 [20140510 19:04:23.190] Lost peer for folder /home/jnihil/phone Then btsync goes silent on Linux. So I wait. Omitting the rescan log which took place. Then even more silence. The Android device returns to the LAN at 19:19 (16 minutes after leaving). I verified that the Linux box can icmp ping the Android. 3 minutes since the Android returning to the LAN and still nothing new in the Linux btsync log. Still pinging the Android from Linux. However I see the Android send out the following via a packet capture: 192.168.1.150 -> 239.255.255.250 SSDP 140 M-SEARCH * HTTP/1.1 192.168.1.150 -> 239.255.255.250 SSDP 140 M-SEARCH * HTTP/1.1 This happens every time I restart btsync on the Android, with nothing appearing on the Linux debug log. No response seen in the packet capture. 3. I then pause/unPause btsync on Linux and the connection establishes as the Linux box interrogates the LAN. [20140510 20:31:09.167] Using IP address 192.168.1.111 . [20140510 20:31:09.168] Loading config file version 1.3.94 . . [20140510 20:31:11.171] Sending broadcast ping for 5 shares [20140510 20:31:11.457] Got ping (broadcast: 0) from peer 192.168.1.150:60276 [20140510 20:31:11.460] Incoming connection from 192.168.1.150:35059 [20140510 20:31:11.658] Got tunnel to 192.168.1.150:35059:TCP, total tunnels: 1 [20140510 20:31:11.658] Best tunnel now is 192.168.1.150:35059:TCP [20140510 20:31:11.658] Found peer for folder /home/jnihil/phone 192.168.1.150:35059 direct:1 transport:1 [20140510 20:31:12.158] Going to send state notify to peer 192.168.1.150:35059 [20140510 20:31:12.159] ping 192.168.1.150:60276 [20140510 20:31:12.159] Checking connection to 192.168.1.150:60276:TCP . . and they sync. So I see 2 issues: 1. btsync on Linux gives up on finding any new peers after losing contact with its inital peers 2. btsync on Android returning to the LAN is not able to re-establish communication with btsync on Linux. Regards.

Hi RomanZ, If auto-sleep is disabled on the Android, the sync is performed after restarting btsync on the Linux hosts. Sync is maintained if both Android/Linux remains on the LAN. However, if the Android leaves the LAN (phone leaves the house, or goes into power-save and turns off the Wi-Fi radio), then returns to the LAN sometime later, the Androids do not see the Linux hosts until btsync is restarted on the Linux side whilst the Android is ON (meaning its wireless interface is UP and not OFF due to power-save). So, a workaround of using cron to restarts btsync on Linux every hour will not work unless the Android device happens to be alive on the LAN at the same time of the Linux btsync restart. Let me find some time this week and get a set of debug logs. I've got a backlog of work to get through, but I'm sure I'll find time. Regards, Jack.

I spoke too soon. The Linux hosts seem to still require a restart for the Androids to sync. Do not have anymore time today to gather a debug log, but this is what I've observed: 1. Disabling auto-sleep on the Android prevents the sync issue (waiting didn't help). 2. Linux requires upnp enabled. 3. Restarting the Linux hosts initiates the sync with the Androids (provided upnp is enabled). Hopefully this week will be a quiet one so I can get you the data needed.

Packet capture on the Linux hosts revealed that they were not resonding to the upnp packets from the Andreoid: Capturing on eth0 0.000000 192.168.1.150 -> 239.255.255.250 SSDP 140 M-SEARCH * HTTP/1.1 3.682471 192.168.1.150 -> 239.255.255.250 SSDP 140 M-SEARCH * HTTP/1.1 I enabled 'Use UPnP port mapping' on the Linux hosts which fixed the sync issue with the Android devices. My understanding was that this parameter was to do with punching a hole in the router/firewall. Looks as though I was mistaken. Strange how the Linux hosts see each other with the parameter disabled... Regards, Jack.

1.3.20 does not help. My wife & kids are off with the inlaws next week, so I'll have time to collect the debug info then.

Actually on the Linux side upgrading to 1.3.87 has made things worse. Now The Android(s) will not sync even after the Linux machines (x2) restart. Linux however sync with each other as before. Not sure if I'll have time to capture the debug logs tomorrow but I'll see if I can punch a hole in my schedule sometime soon.

It's version 1.3.86 (Linux - arm & amd64) and version 1.3.19.0 for Android 4.1.2/4.2. I found by accident today that the Android devices will sync with the Linux machines ONCE if I restart btsync on the Linux side. After that one sync no more syncing amongst Android/Linux, though the Linux machines will happily sync with each other whenever changes are made to the folders. Curious. I will try and find some time tomorrow and see if I can get a coherent set of debug logs from the machines.

I'm experiencing the same. Until upgrading to the recent update. all btsync devices (Win7, Linux, RasPi, Android) were suncing well. After the update all 3 Android devices will not sync. Win7/Linux/RasPi are okay.

Hello and thanks for the great effort. My wishes are: 1. following symlinks 2. predefined host:port on the mobile clients Thank you.