Jack Nihil

  • Content Count

  • Joined

  • Last visited

About Jack Nihil

  • Rank
  1. 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.
  2. 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.
  3. Hi RomanZ, I had some time to investigate this issue today. Setup: Android 4.1.2/btsync - IP: Ubuntu Linux 13.10 (kernel 1.3.94 - IP: 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 [20140510 19:00:19.101] Checking connection to [20140510 19:00:19.102] Checking connection to
  4. 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
  5. 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.
  6. Packet capture on the Linux hosts revealed that they were not resonding to the upnp packets from the Andreoid: Capturing on eth0 0.000000 -> SSDP 140 M-SEARCH * HTTP/1.1 3.682471 -> 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... Reg
  7. 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.
  8. 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.
  9. It's version 1.3.86 (Linux - arm & amd64) and version 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.
  10. 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.