GreatMarko

Yes, but this thread is 8 months old!! At the time it was started, the mobile apps hadn't been released!!

Control4 say BTSync is putting "bad packets" on the network? Whilst Sync does generate a lot of network traffic, it doesn't generate continuous streams of "bad packets"! All software that relies on a network connection sends/receives the odd bad packet of data from time to time - not intentionally, but sometimes packets can become lost/corrupt in transit. I would say the ownness is just as much on Control4 to make their software more tolerant to "bad packets" of data! Anyway, in the meantime, you could consider limiting the bandwidth (rate) in Sync to reduce the amount of traffic on your network - this may then allow other software to utilize your network more

If you're syncing an ENTIRE drive, and not all the files are syncing, it's likely to be due to; Sync isn't able to access some files (because they're currently open/locked/in use in other applications) Sync isn't able to access some files (because they're protected system files/folders - for example System Volume Information) Some of the folders/files on the drive are being excluded by the rules in your .SyncIgnore file

Yes, read-only nodes can transfer data between them. The same rules with "4MB chunks" apply to read-only nodes as they do full-access nodes i.e. small files are transferred in their entirety, larger files are transferred in 4MB chunks. For more information, please see the "When a file changes, does BitTorrent Sync transfer the entire file again, or just the part that's changed?" entry in the Unofficial FAQ

Whilst folder_rescan_interval can't be "disabled" as such, however, the highest value you can set it to is 2147483647 (seconds) i.e. a very, VERY long time! That said, even though no files may be syncing from your read-only device to your full-access device, read-only devices can still share data between them, and therefore, Sync still needs to keep track of what's in each folders. For example, if you have 3 devices syncing, Device A which is "full access", and Devices B and C which are both "read only", A will send data to both B and C, at the same time, B and C will also exchange data between them. to ensure that data from A is available on both B and C as quickly as possible. So, in summary, Sync needs to maintain an accurate record of the contents of the folders you add to Sync, and therefore, folder_rescan_interval is still important variable, even on read-only devices.

First of all, the latest builds of BitTorrent Sync (1.2.82) - whilst still technically "Beta" are a LOT more stable than they were in the early days of Sync! I run Sync on a couple of Windows Server 2012 R2's without issue! In terms of Mesh/Hub+Spoke - Sync by its very nature is a "Mesh" setup (I suppose you could mimic a Hub+Spoke setup using read-only secrets - but it depends whether you're trying to "sync" all 3 of your servers, or just backup one to the other two) Pre-seeding isn't natively applicable to BitTorrent Sync. However, I guess the "encrypted node" ability currently present in the Sync API would be the nearest equivalent. My advice, if you're wanting to keep data Sync'd between your 3 Windows servers is go for it! ...BUT do bear in mind that whilst Sync is now pretty stable, it's still technically still in "beta", so be careful if you're syncing critical data that you don't have backed up elsewhere!

Sync's aim is to try and transfer files as quickly as possible, therefore "priority" is essentially based on how quickly each peer can deliver data, regardless of whether it's on a Wired/Wireless LAN or WAN. Now generally speaking wired connections are faster than wireless connections, and LANs are faster than WANs. However, if in your case your LAN transfers are slower than your WANs, there are a couple of settings within Sync that you could try and change to see if this improves your LAN transfer speed: The advanced settings to try changing are: "lan_encrypt_data" - set this to "false" "lan_use_tcp" - set this to "true" ...and also untick the "Search LAN" option (this is a per-folder setting), as enabled this can dump a lot of multicast traffic on your LAN, which could reduce overall speeds.

I have Sync running on a couple of Atom devices (not the Dell Venue 8 Pro though) without issue - so it's not the CPU itself that will be causing your issues.

Your question is answered in the Unofficial FAQ - please see the "Is there a limit on the number/size of files I can sync?" entry

A couple of things to check... Check that there is enough free space on your devicesCheck that the files/folders you're syncing aren't currently open/locked/in use by other applications

Is Sync able to establish "direct" connections between your devices, or are the connections "relayed" (Please see the unofficial FAQ for how to determine this) If your devices are not establishing direct connections, this will likely be the cause of your slower speeds.

As Harold has indicated, "real time" sync very much depends upon the host operating system, as not all OS's can detect changes to files instantly. As a "fall back", Sync has an advanced "folder_rescan_interval" setting that causes Sync to rescan the folders it's monitoring every 600 seconds (10 minutes) by default to pick up those changes that weren't detected in real-time. If your using an OS where updates to the file system are not instantly picked up by Sync, you could lower the "folder_rescan_interval" so that the "fall back" scan occurs more frequently. Note: If you set this value too low, it could lead to excessive disk/CPU load, as every file/folder being monitored by Sync will be rescanned at this recurring interval

Yeah, it's generally assumed that you're not running any other backup/synchronization software on the same set of files/folders that Sync is acting - because, as you've found out, this causes lots of problems! But thanks for posting your update, as I'm sure this will be useful for others to note! Glad you're up and running now though!

It's likely to be a sub folder of the C:\ drive that you don't have permission to access, rather than the entire C:\ drive itself. For example, if you're running Sync as a regular user, and not as an administrator, Sync won't be able to access other user profiles present on your machine (generally found under C:\Users) You'd therefore be wise to exclude such sub-folders from being included in your Sync. The other reason it would be wise to exclude the C:\Users folder from syncing is because the settings/database files for Sync itself and located within this tree. Syncing this folder may cause issues. Finally, please remember that Sync is primarily a file/folder synchronization tool - rather than a backup tool. Attempting to sync your entire C:\ drive without any exclusions will mean that data will be constantly transferring the entire time your computer is in use (i.e. whenever the page file changes, etc). You may be far better with dedicated backup software that can take daily/weekly backups of your C:\drive at fixed intervals, rather than "continuously" syncing every single change made on your C:\ drive - which is what Sync will do!

No, Sync should "merge" the two sets of files (assuming you're using a full-access secret on both devices) and the file names are different (i.e. there are no conflicting files in the folders - in which case, whichever is newer will take priority) If some folders are syncing but others aren't between the same set of devices, it's unlikely to be a firewall issue. I'd suggest double-checking the secret you're using for the affected folder is correct and identical across all your devices, and is a "full-access" secret on at least one of them. (if they're all read-only secrets and there's not at least one "full-access" secret, nothing will sync between them) It would also be worth checking that you have plenty free space on all your devices. If none of these solve your issue, I'd suggest removing the folder from Sync on your devices, and then re-add the folder again with a newly generated secret - this will prompt a reindex of the folder, so if there were any issues with the initial indexing, removing and then re-adding the folder will likely resolve this. There are no limits on the number of devices you can sync between

A very Happy New Year to you too, saruman! Sounds to me like it's a problem with your router not being able to handle the amount of traffic that Sync is generating. I'd suggest rate limiting your Sync connections (Preferences -> Limit download rate/Limit upload rate) to see if this resolves your issue as well as checking your router settings (that it's not "banning" client's that "flood" the network with excessive traffic, for example). Your router log may also give an indication as to the nature of the issue - either way, the problem will be caused by your router.

That's really strange - but I concur!! I've just manually modified an existing secret (that didn't previously contain a 9 to now contain a "9"), and as soon as I did, Sync crashed!! (1.2.82 / Win 7 64-bit) Restarting Sync then produces an "Error: Don't have permission to write to the selected folder" for that folder (even though it retains the original secret before I changed it to include the "9") - very strange!! I've reported this to the devs

Subfolders already automatically Sync as part of the parent sync they belong to - are you referring to "nested shares" i.e. syncing a sub-folder independently of a parent folder? No, if Sync isn't running on your mobile devices, files/folders won't Sync This is usually resolved by increasing the value of the advanced "folder_rescan_interval" setting

It has been hinted at by the developers that such ability will be coming to the Enterprise/"Business Grade" edition of Sync Do bear in mind that "reverse engineering" "the software" (a term that BitTorrent Inc's Legal Dept have confirmed also incorporates "the protocol") is against the Terms of Use

Remember that Sync is currently in "Beta", and memory/cpu consumption will likely be improved before Sync leaves "beta". It has already been improved on a number of occasions with new Beta builds, but then subsequent Beta builds can have a higher memory/spu consumption. This is to be expected with "Beta" software, but will likely become more stable as the beta progresses. This has been discussed in a number of threads, but the general feeling from the developers seems to be that Sync is primarily a file synchronization tool to keep your files synchronized between devices - it's not primarily a "file copy" or "backup" utility. Presently, if you wish to sync between an internal drive and an "external" drive, your external drive must be a compatible NAS drive. "Selective Sync" (already possible in the mobile apps) is also planned for desktop editions of Sync This functionality - encrypted nodes - is already present in Sync - although currently only via the API

This is a dedicated forum for BitTorrent Sync - a file synchronization tool - you might have more luck posting you non-Sync related question over in the correct forum

There have been a number of changes to the format/length Secrets during the alpha/beta phases, therefore, to maintain a degree of backwards compatibility, other "variations" may still be valid (For example, before "read-only" functionality was introduced, Secrets could start with any letter - and these secrets are still valid now!). Also, when "read-only" secrets were first introduced, they started with an "R" - and they are still valid too! However, the current convention - in the latest Beta builds - generated "full access" secrets start with an "A", generated "read only" secrets starts with a "B", generated "one time" secrets start with a "C"

No, you can also manually create them yourself! Just make sure your secrets start with an "A" for a full-access folder, or a "B" for a read-only folder. Also, avoid websites that claim to generate "secrets" for you - they are scam sites, and not endorsed in any way by BitTorrent Inc

Sync isn't a "streaming" service - it's a file synchronization tool. Therefore you can't "steam" music without also downloading it to your device

You will do. (this is listed as a "Known Issue" in the Documentation) The only solution at present is to ensure that there is adequate free space on the devices you're syncing between.