Andy22

Encryption was always disabled, but we gave up on Btsync a while ago. Syncthing was much faster inside a LAN, but had lots of actual sync problems. We use CudaDrive now, which simply avoids syncing altogether and just uses a local cache, which is simpler to handle and more reliably.

Only problem is DD-WRT 3.0 does not come with a "file" or "readelf" binary... PS: Guess now i need to find out where i can grab a arm compatible readelf binary that runs on the router. I realy do not want to invest the time and install the DD-WRT toolchain and compile my own binutils. What clib you compile against btw? Maybe you might consider linking statically against MUSL in the future to prevent such cases for embedded devices?

Yes i did download the arm binary and extracting and setting the execute flag simply results in: ./btsync-sh: ./btsync: not foundThis seems to indicate that the binary is not recognized as compatible executeable, since the file exists in the directory and has the +X flags. I can also run other binarys from the same location just fine. model name : ARMv7 Processor rev 1 (v7l)processor : 1BogoMIPS : 2655.84Features : half thumb fastmult vfp edsp vfpv3 tls vfpd32CPU implementer : 0x41CPU architecture: 7CPU variant : 0x4CPU part : 0xc09CPU revision : 1Hardware : Marvell Armada 380/385 (Device Tree)Revision : 0000Serial : 0000000000000000

Hi, there seem to-be a ARM binary, but it seems its not ARMv7l compatible so i can't run it on the latest lineup of openWRT compatible ARM routers/NAS? Getting BTSync to compile on openWRT should be relatively simple, since they have a good toolset in place and are very close to a "real" linux distribution in terms of available packages and there use of a extroot overlay filesystem. So is there a package available that is compatible and can be used on those ARM V7l, A9 Routers running openWRT/DD-WRT?

Just tested Syncthing on the exact same LAN using the same folder to sync and got speeds of 30~60 MB/s. The initial sync just took 30sec, compared to 5min for BTsync.

Hi, i wonder if there is a particular reason why LAN sync speed is only 1/10 of the maximum possible speed? Our LAN speed measured via SMB transfer can sustain 110 MB/s, while BTsync (2.1.1) varies between 500kb/s - 6 MB/s. Thast what i have already done: 1) disabled "disk_low_priority" 2) increased send/recv buffers from 10MB to 32MB So is BTsync designed to-be able to achieve at least 50% of a GB LAN ~50Mb/s? We often have to sync large files and only reaching 5-15% of the possible LAN speed is realy bad, even dropbox LAN sync was able to reach 10-15 MB/s. We where assuming that BTSync will "surely" beat Dropbox inside a LAN, but we struggle to understand what the problem is or maybe our initial assumption was simply wrong? Anything else i can try? thx Andy

After upgrading to 1.4.103 and a clean resync, deleting all on my cloud node and the local sync mata data files, i no longer see this error. So i guess at least for me .104 fixed it. Thx

Just tested the 1.4.99 version and have the same problem, this also seems to cause the "out of sync" error and will stop syncing. On top it also results into thousands of log file entries and notifications. I really consider switching back to the 1.3 version, since nearly all 1.4 versions had some kind of problem and currently this bug prevents me from using btsync at all.

Hi, i use BTSync 1.4.93 under nas4free (BSD 9.2, 32bit) and i get tonns (100+ log entries) of this message in the logfile notification? I do not recall something similar for the 1.3 versions, what is this messages meaning?

There exists a extension here: http://forums.nas4free.org/viewtopic.php?f=71&t=5704

See those lines too in 1.4.91, any idea what causes this?

A simple "Team Server" option for your cloud sync mirror server, like seen at the competitor AeroFS. Its kinda confusing to setup your own cloud mirror node, so that it acts as mirror/seed only. I guess u need to enable "Restore modified files to original version" for the server folders and use Read-Only keys on the server? The idea is that u never change files on the server itself, so if the server gets bugged or is lost/compromised, it should not sync server side changes to the "real" clients. I wish there would be a simple way to enforce those rules, since atm its kinda unclear and u have to setup things per folder. Thx Andy

Google brings up http://forum.bittorrent.com/topic/19228-latest-sync-build-1170/page-6 where it notes: The official help pdf notes: So the forum basically says, (file_size < max_file_size_diff_for_patching) = patching is used, while the pdf notes (file_size >= max_file_size_diff_for_patching) = patching is used. The default value is als "1000", so going by the PDF its 1000 Mbyte aka 1 GB? So who is right here now and can someone give a actual example? Both statements are kinda confusing to me, since the first would mean that all files < 1GB will use pathcing, while >1GB wont? This would mean that a 10GB truecrypt container wont be patched, which is unlogical so i assume the first statement is wrong. Going by the PDF this would also mean, that only files >= 1GB would be profiting from patching, wich i also find hard to believe, since 1GB is a rather large default size? Maybe the size is in kb? If the second statement is true, lowering this value should improve sync on files like PSD's or other formats, where only a few blocks might change? thx Andy