leo

I have a mixed structure: 1 Client on Win 7 64 Bit (Vers. 1.1.33) (1 Client on WinXP SP3 (Vers. 1.1.33) - currently offline) 1 Client on ARM (Raspberry Pi) (Vers. 1.1.33) 2 Clients on Android 4.2.2 (Galaxy Nexus and Nexus 7) (Vers. 1.1.12) All Clients were in sync at the beginning. All devices were online and btsync was running. First the XP-Client was offline. Now I changed a file on the Win 7 computer. The first client to sync was the Raspberry. It copied the file correctly from Win7 to Raspberry. Then the Nexus 7 synced, but this time the Nexus 7 copied its (old!) version back to the Raspberry and the Win7 Computer. Then I copied the correct version back from synctrash of the Raspberry to the sync folder. Now it synced correctly to both the Win7 and the Nexus 7. The Galaxy Nexus was slow, but now also synced correctly. I changed another file on the Win 7 computer (this time a null-change so I don't have to search for the old version ;-) ) and now it was the Galaxy Nexus that copied back the older version. The Raspberry was the first one and this computer first synced in the correct direction - and then also copied the old version pushed from the Galaxy Nexus. Now I also switched on the XP-Client. Waited until it was in sync. Then changed a file on Win 7. It was correctly synced to the XP and the Raspberry. After a short while it was correctly synced to the Galaxy Nexus. Strangely the Nexus7 didn't sync for a while - about 10 Minutes. I looked around and found that the filelists in BTSync on the Nexus 7 weren't correct. On the remote side there a file was listed as existent that wasn't there since some time (note: All the clients stated that they were in sync and the file was missing before they synced) On the local side only one file was reported by BTSync. But in the filesystem the correct number of 2 files were existent, Some time later the Nexus 7 suddenly synced. Now he copied his local copy of the file I had changed on Win 7 -> wrong direction! And this also was the file that was missing in the BTSync-List locally but was existent in the filesystem on the device. Looks that there is a problem with the Android Client. I don't know it that matters: All computers except the Raspberry are configures with a timezone of CEST. The Raspberry is in UTC - 2 hours ahead. But I assume that the internal timestamps are already UTC. Another note: I also assume you are aware ot the timestamp bug in the current Android versions? (You can not change the timestamp of a file so every file gets the timestamp it was created on the device an not the timestamp of the original file that was synced.) [update] I played a little more. What is strange is that the filelist in the BTSync-Client on the Nexus isn't correct. Now it states that there is no local file whereas there are two files in that directory. Before it states that there are 3 files in the remote directory whereas there were only 2 in reality. Only after I recreated the file and then deleted it this was recognized by the Nexus 7. Restarting the BTSync-Client on the Nexus 7 did not change the behaviour. The Galaxy Nexus also sent a new version into the system after the Nexus 7 sent his (wrong) Version ... HTH ML btw.: Power consumption and usage of mobile data now look O.K. on Android.

I accidently noticed that. The place for this announcement seems to be suboptimal to me. As the Android-Version has its own version - wouldn't it be better to create a separate topic for the Android-Client? Nobody expects a new Android-Version in a topic for a client with another version number and for differend operating-systems.

Well, my last post indicated that the link there might be a litte too muc hidden - I overlooked it when I searched for it. Now I found it and it points to the current version (Section Android Client). But maybe it is an idea to put it (also) to the other download links in the General Section?

Well on the main page there is no Android client offered. Then there is a link to the corresponding forum post. Maybe the link to the latest Android-Client is buried deep inside the text, but the first download links only point to the latest "package" to download. In this case it was the 1.1.33 which didn't include an Android-Client. So one has to go backwards to find the latest one ...

The latest one (1.1.12) came with the desktop 1.1.30: http://syncapp.bittorrent.com/1.1.30/ A new one is announced soon.

Great to hear ;-) In this case it can't be the issue with the Android Media server as the same content was placed on the devices before without problems. And also I observed this only in 1.1.12 and not in 1.1.7 - with the same set of files to be synced.

See also: http://forum.bittorr...ata/#entry57830 I upgraded to 1.1.12 on Android 4.2.2 With Wifi off and Cellular Data on and "use cellular data disabled" in BTSync the client vanishes from the list of connected devices on the other clients connected. But the counter for mobile traffic still rises for this app. The other thing I noticed: The power-consumption is still quite high although the device is in sync an nothing is to be transferred (this with WiFi on). There is also a new process called "Media" with a subprocess "Download manager" that now consumes a lot of energy. This is new since 1.1.12

Using BTSync 1.1.7 on Android 4.2.2 "Use Cellular Data" is disabled. But I see 4 MB of Traffic generated by BTSync on mobile data (most of it in background mode) With cellular data disabled I expect this value to be 0. And also this seems to be quite a lot of traffic for less than half a day without having to synchonize any data.

(Using BT-Sync 1.1.27 oin Windows 7 64 Bit and 1.1.7 on Android 4.2.2) I also observe that folders already synced and were not changed occasionally are marked as out of sync After a while they are marked in sync again (but without any transfer in the history) It looks as if power-save might play a role in this, If the device is in use it seems that the files keep in sync. I observed the following problem: If a file gets deleted at the PC while btsync on Android is not running, the Android-Client will retransmit the file to the PC after restart of btsync. If btsync was running and only no network connection, the behaviour is OK. Then the file will be deleted on the Android-Client. (One might to stop btsync on Android due to power consumption - OK, not very much in idle state but noticeable) Wishlist: - better notification for the syncstate. The optimum would be to indicate if anything has changed locally, separately indicate if anything has changed remotely and indicate if there are active transfers. Within the app a logfile-viewer would be nice so that one can see what currently is happening.