liefde

Here's what I've been doing for about 2 years now; Use cryptsync and have the truecrypt mounted volume drive-letter as the unencrypted side, and a btsync folder or subfolder as the encrypted side. CryptSync syncs, btsync sees updated files and syncs them on network in turn. By the way, for Windows users with SSD it might be a better idea to use DiskCryptor instead of TC. I've been quite happy with it, and it's even lower on resources in Windows 7 x64..

So, I just want to add a couple of folders, with audio and video recordings, and images and some other smartphone originating files, but I can't add any!? I want to add them, then copy the RO link of each folder to the remote syncs, so the remotes don't touch my android sources. What's with the totally un-userfriendly android version? Just offer us the exact same thing as the server and desktop. I don't see QR codes in my PC btsync by the way, so adding folders with that weird workaround is not really worth the crap if it's all RW. What's with the weird uncapitalization of the title in this forum? I typed Android backups to PC and NAS not Android Backups To Pc And Nas

For crying out loud, this is still not fixed? Do we really need to proxy via nginx?

You only need an open port on the listening side. In this case, the tracker port is a remote server, your btsync clients have no problem connecting to them. The tracker is listening on port 3000. Your clients aren't trackers. They do listen on a port however, which you can set to a static one in the settings (as I understand it, and it seems to do what I expect that to do), in which case you don't need to use uPNP. For each client's listening port you *do* have to open the port through NAT on your router or firewall. That's from the outside in, so the outside sees that btsync is listening on that port.

Next time don't be so eager to lock a thread when even the TS has not had time to respond to the useless (and bad) 'arguments' for not supporting it. XP x64 uses the same codebase as Server 2003 x64, 99% of its hotfixes are working perfectly fine in XP x64 Edition; http://www.ryanvm.ne...opic.php?t=9162 And indeed, there has never been a SP3 for XP64 because there is a huge difference with XP x86. As far as I know, XP x64 is so rarely used because it is released using Volume Licenses internally, and Microsoft made a couple of silly mistakes with those when another team finished Vista x64 early, but hey, that is inside knowledge they prefer not to be too well-known. XP x64 is their secret, best OS ever to appear on the market, but they'd lose a LOT if audiences would stick with XP x64 instead of going the road of the stupidified 7 or 8 designs. Oh and then the idiots stating "the rest of the world has moved on" when it's quite clear XP x64 Edition is still performing way faster with current day hardware than Windows 7 or WIndows 8 ever will. Not even mentioning how buggy Windows 7 still is today, while my XP x64 machines never freeze on me one bit. One great clue on that fact might be that many IT-folk and scientists in general, but especially those who do benchmark and testing research at Micron Technology are still using XP Pro x64 to do their (best) IO testing on for NAND and SSD development in general. Maybe that's why you should care. Obviously 'the' developers are having a hard time supporting XP x64 Edition, because, guess what, they're as lazy as most of you, it's extra work. Here's a clue: Open source your Sync app code, we'll make it support XP64 for you, you dimwits!

"Given that Microsoft themselves will cease support for XP in April 2014, it's probably time to consider upgrading anyway!" Oh please. F_ck that. I will be running some systems on XP64 for many years to come. By the way, it installed and seemed to function just fine on XP Pro x64 Edition. Sad you don't support it. I did notice that suddenly randomly BTS has lost its folder data on an XP x64 machine, but I doubt that the OS is at fault here, because it happened on a Win7 laptop as well.