GreatMarko

If you disable the Tracker, Relay and DHT options, Sync should remain confined to your LAN and not venture into the WAN (other than to check for updates - which you can disable)

Please update your Android Sync to 1.1.21, as this may solve your issue! ...and no, to my knowledge there isn't a "Debug Mode" for Android, only a "Found an issue? - Send Feedback" button at the bottom of the Settings screen

Yes, dumps should be stored in %AppData%\BitTorrent Sync (and not as hidden files). They will have file names along the lines of "12345678-sync.1234.dmp"

Please refer to BitTorrent's general Terms of Use, specifically Section 4b, which states: 4. Use of software b. If no license agreement accompanies the Software, use of the Software will be governed by the terms of this Section 4b. BitTorrent grants you a personal, worldwide, freely revocable, limited, non-transferable, non-sublicensable, royalty-free, non-assignable, nonexclusive license to use the Software for personal, non-commercial purposes in the manner permitted by the Terms. You agree that you will not decompile, reverse engineer or otherwise attempt to discover the source code of or distribute the Software. Notwithstanding the foregoing, decompiling the Software is permitted to the extent the laws of the jurisdiction where you are located give you the right to do so to obtain information necessary to render the Software interoperable with other software, provided, however, that you must first request the information from BitTorrent and BitTorrent may, in its discretion, either provide such information to you or impose reasonable conditions, including reasonable fees, on use of the Software to ensure that BitTorrent’s Intellectual Property Rights in the Software are protected. You may not assign (or grant a sublicense of) your rights to use the Software, grant a security interest in or over your rights to use the Software, or otherwise transfer any part of your rights to use the Software. For clarity, your use of the Software is also subject to the disclaimers and limitations in Sections 13 and 15 below and your compliance with the export control provisions of Section 18.

What version of you using now? Are you still on 1.1.30? In which case, 1.1.42 is available, and does fix a number of crashes.

Try changing the advanced setting "lan_use_tcp" to "true" - this will force Sync to use TCP instead of UDP connections... it might work for you!

No.

I hope so, as I agree, it's a little frustrating! That said, once the auto-update feature is fully working/implemented, and new builds are made available through that mechanism much sooner after they are released than at present, the need to manually download/install if you really can't wait to get your hands on the next build should be negated! Hmmm.. not sure on this one to be honest! Two thoughts spring to mind though; Firstly, I wonder that maybe if the "silent" in-place update fails for some reason that it then reverts to the standard "full" installer, which is why you then see the various dialogs and "sync is already running" message? The other thought would be that if your devices are "slow", and the updater attempts to automatically close a running Sync copy before proceeding with its silent update, if the Sync task hasn't exited/terminated in a timely fashion, the updater detects that Sync is still running, and you'll see a message accordingly.

Great! Glad it's working for you now! I suspect your earlier issue was due to higher than usual traffic levels to BitTorrent's servers, given that Sync has literally just gone into "beta" in the last few hours!

Well, the second point that the previous poster made, was that "Auto-update doesn't seem to work for me." There was no reference made as to whether auto-update had announced that there was an update available, but that it subsequently failed to download/install. It was therefore assumed in my response that "auto-update doesn't seem to work" was a reference to the common message that users often see when they check for updates, with the knowledge that a newer version is available, only to be informed that their client version is already up to date! With that in mind, my response to the previous poster's point was valid. If, however, you've been experiencing a slightly different issue to the previous poster, that of a failed/incomplete download, it's quite possible that there has been a higher than usual demand on BitTorrent's servers/infrastructure over the past couple hours, given that Sync has just gone into "beta". As you say though, you have now been able to download, but this is a likely explanation as to why your download may have failed for you earlier, given potentially higher than usual levels of traffic.

Are any other programs currently accessing content within your /home/chad/Music folder, as this would explain the behavior you're seeing. If files are in use/locked by another process/application, Sync will indicate the amount of data to be transferred but won't actual begin transferring it until the files in question are released by whatever other process/application is currently using them,

Yes This is normal - but it does cause a great deal of confusion for users! It can often take several days/weeks before new builds are pushed out via auto-update. If you don't want to wait, you can always manually grab the latest build here: http://forum.bittorr...ync-build-1142/ Yep, I asked this several months back! It is a little frustrating, but it affects all users who manually update. Hmmm... what version was this happening with? The auto-update feature (when it works!) should silently download the update, install, and restart Sync without additional prompts

That's actually a really interesting idea! I'm also curious to see if this can be implemented!

What version are you updating from? What error are you seeing? You can also manually obtain the latest build here

It's difficult to be more specific as every make/model of router is different (I'm assuming it is indeed a router, rather than just a switch when you say "hub"?), but basically most routers have security settings built that can either either block certain traffic/ports, or prevent other devices on the same network seeing/communicating with each other. You may need to refer to your router's own documentation for details of the specific security features/settings on your router, but you should be able to disable them/add exceptions, etc

Whilst you had disabled your firewall in Windows, it sounds like your issue was likely to be a firewall/UPnP/routing issue with your router!

You can always turn off the "Search LAN" setting (a per folder setting) to reduce significantly the amount of multicast traffic on your local network! With this setting disabled, if your local devices can't then find each other, but they all have static IPs, you could use the "pre-defined hosts" options to identify them to Sync

It's a known bug - but nothing to worry about, as it doesn't affect operation of Sync in any way - please see this thread

You would need to do the following: 1) Copy/save the current secret for your "C:\Users\blah\BTSync" folder 2) Remove the folder from BitTorrent Sync 3) Manually copy/move the data from "C:\Users\blah\BTSync" to "D:\BTSync" 4) Add "D:\BTSync" to Sync using the secret you previously copied/saved

Agreed! Yeah, Sync used to do the same with .SyncTrash folders - even if you'd configured Sync not to delete to .SyncTrash, the folder itself would still be created/present.

It's not just about "hiding" files (for example, on Windows, .files are not hidden by default)... it's more to do with the default sort order of file/folder lists, which for most users will be alphabetically, meaning that files/folders starting with a "." will appear right at the top of the list. If "SyncArchive" doesn't start with a dot, it'll appear much further down the file/folder list, making it very easy to overlook, and potentially inadvertently delete! ...that's why it would make more sense for it to start with with a "." just like .SyncIgnore and .SyncID do, so that it appears near the top of directory listings!! You can simply change the per-folder "Store deleted files in SyncArchive" setting to "off"!

Yes, this issue has been kicking around for a while - don't worry, it doesn't affect the running of Sync in any way, it just means timestamps in the logs are off by a month (It's basically to do with months being numbered from 0-11 instead of 1-12)... but as I say, it's nothing to worry about, the developers are aware of this, and it will undoubtedly get fixed at some point (although it's probably not considered a 'top priority') BTW, Sync 1.1.33 is now available - please consider updating

If you're trying to sync your entire %AppData% folder, have you made sure you've excluded the %AppData%/BitTorrent Sync folder from syncing? ...if not, this will cause you problems!

Yes, it does

If you'd deleted your %AppData%/BitTorrent Sync folder that would likely have solved the issue for you too!