vocatus

I think the issues are threefold: 1. Suddenly being charged for functionality that previously existed, when the community was explicitly told that wouldn't happen 2. Community feels used by BitTorrent Inc. A number of people have spent a lot of time essentially acting as free testers for the BT Sync team, only to be suddenly expected to pay after providing all that free work. 3. $40 is a steep price (if you don't believe me, look at the analysis of Valve's Steam Sale methodology - cheaper unit prices generate higher total revenue), especially as a recurring subscription fee. I can only speak for myself but I'd happily pay for BT Sync....once. Heck, I'd even be willing to pay a small upgrade fee if a new major version came out. But I will never pay a subscription fee. Right there BitTorrent Inc. lost a paying customer and gained nothing from it. And based on the feedback in this thread, I'm guessing I'm not the only one. They are literally pushing paying customers away by insisting on a subscription-based model. Of course complaining is useless without a recommendation, so here's mine: Charge something reasonable like $9.99 and watch sales increase substantially. Additionally, removing the folder limit (if even only for a while) would be a show of good faith to the community that's spent so much time beta-testing Sync for free. I love BT Sync, use it heavily (I maintain and distribute the Tron project with it) and admire the work the Sync dev team has done. But just like if I started charging people in the Tron community after they've spent combined hundreds of hours testing the program for free, the Sync business management team would do well to re-evaluate their approach to monetizing the product without alienating the core user base - which are the people who recommend Sync to their peers.

I echo what everyone else is saying. 1. What service exactly is BitTorrent providing that justifies a $40/year subscription fee? $40? Really? To do what, run an optional tracker server? 2. "All features available in 1.4 will be in 2.0" Except for the new arbitrarily-crippled folder limit. This has a vaguely sleazy feel to it. On the plus side, one benefit of this business decision is to push more users to SyncThing and spur development of that already-excellent app further.

Hi RomanZ, thanks for replying. I'd use UPnP but can't use it at work, so just relied on doing it manually. Here is the configuration on the work side. Here is the configuration on the home side. Tracker server is enabled and the provider doesn't NAT us; all WAN IP's are public. Is there a way to see why it isn't connecting?

I have two BTSync nodes, both running latest client and both running Windows 7 pro with all patches applied. I cannot, for the life of me, get them to sync without using the relay server. I've disabled Windows' firewall on both ends. I've forwarded the correct ports in my pfsense routers on both ends. How can I fix this?

Hi there, Wanted to chime in with a couple issues I'm seeing with this release. First (big one): Devices won't sync until I kill BT Sync and re-open it. For instance, I changed some .txt and .bat files at home on Saturday, and came into work on Sunday to find those files had not updated. Once I closed BT Sync on both hosts (home and work) and relaunched it, the changed files suddenly synced. Both hosts are Windows 7 Professional, with correct time set, and both running the latest build (.109). Second: On the sync repo server for Tron and PDQ Deploy, I'm also seeing the "infinite uploading" problem. But, I'm guessing this may be due to peers on the other end who are running outdated versions. Thanks again for all the work you guys put into this.

Any option besides a hard cap would be great, there are a number of use-cases where more than 50 peers is very desirable.

Enabling DHT on the individual share can raise the limit (it seems to around 75-100), but the log file still fills with errors about "PEER LIMIT REACHED," so it's only a partial fix. Developers, can you comment on this issue please?

I've posted about this before and was told "no updates at this time," but this is a pressing need and a very easy fix. Please, remove the 50-peer hard cap in BT Sync!! Abolish it, raise it significantly, or add a GUI option to let it be configurable, This cannot be a difficult change, and I can't imagine what possible negative effects there could be. I'm attempting to host some projects for people to use and am constantly bumping into this hard peer cap issue. I know the team is very busy, but this would be extremely helpful if you could find time to implement it. Thank-you.

Hey Vildhet, some good news. After installing the latest version and letting it run for quite a while, it seems that a) it isn't crashing any more, and it does connect to a lot of peers now, about the same amount as previously. It takes longer to get connected than with v1.2.91, but does end up connecting. So we can probably consider this thread closed. Thanks for your help.

OK, it isn't crashing now, but it's still connecting with far less peers than normal (~20 instead of 50). I have debug logging turned on but am not seeing anything specifically related to peers. What next?

Sure thing, I'll load up the latest version (appears to be 1.3.94 as of 2014-05-10) and see if it crashes again. The primary problem I'm experiencing is that it will not connect to very many peers as compared with v1.2.91. A significantly reduced amount (from 50 down to about 10, if I'm lucky).

Thanks for the update, change log, and hard work. Keep it up.

@RomanZ, any update on this?

Just a quick update, the latest version (v1.3.89) continually crashes for me on Windows XP SP3. When it does stay running, it only maintains about 20 connected peers across two shares. When I roll back to v1.2.91, it works fine and suddenly connects to about 30-40 peers per folder share. Currently still running v1.2.91 because I have hosts needing updates, but I can roll back to v1.3.89 for more log collection or testing if you need.

Hi RomanZ, Thanks for the quick response. When I started Sync and waited a couple minutes to collect logs, it crashed. :-P I submitted the crash report via the in-app pop up. Log is attached below. sync.zip

First I want to say thanks to the Sync dev team for your work on Sync - it is a fantastic project and very helpful to myself and a lot of others. So, thank-you. Moving right along... I distribute and maintain a repository of packages for PDQ Deploy (example). I've previously asked about getting the hard-coded 50-peer limit raised, removed or converted to a user-configurable variable (here). I recently upgraded BT Sync on the repo server from v1.2.91 to v1.3.89, and have noticed it now connects with a significantly reduced number of peers. Previously it would quickly hit the 50-peer limit; under the new version it struggles to keep around 20 peers connected. Because of this I was forced to revert back to v1.2.91 until it can be resolved. Was the peer limit reduced or any major protocol changes introduced in v1.3.89? Edit: changed version to v1.3.89 (not .87)

Alright I posted it there. Thank-you for your help.

Peer Limit: I sync with a large number of peers (see related thread here) and a variable//option in Advanced Settings to raise the limit on Max Connected Peers would be super helpful. Thanks!

Hi nils, thanks for replying. I have the ports forwarded directly to my Sync repo, so that shouldn't be an issue. There's consistently 50 peers connected (or it looks to be that way, hard to count the list). I do have two Sync hosts behind the same NAT, but they're mapped through different ports so I don't think that's the issue. How can I submit an official request to get the max peer limit changed to a configurable option? (say, under advanced settings with the other less-common settings) edit: I forgot to mention, if I manually add the repo host (under manual peers) then it will sync up.

Hi nils, I'm seeing the message 1,902 times in each log file, and having a number of users complaining they will never talk to the repo. Additionally, I launched a fresh VM running Sync and it was not able to pull down the file from the repo because it's max number of connections were reached. I understand what you're saying, that peers should just sync up with other peers, but for some reason it seems this isn't happening. How can I increase the limit?

Hi there, I build and maintain a repo of PDQ Deploy packages (example), and have a large number of hosts syncing from me. This is the read-only key for that folder: BTRSRPF7Y3VWFRBG64VUDGP7WIIVNTR4Q lately people have been complaining they can't sync with my server. I enabled debug logging and see messages about "max peers reached, skipping peer xxx.xxx.xxx.xxx" How can I increase the max number of peers? I really need to sync with more peers. thank-you