• Content Count

  • Joined

  • Last visited

  • Days Won


About fragtion

  • Rank
    New User
  1. Is there any consensus yet surrounding this problem? I've tried v1.4.103 and it did not solve my problem with 1xRW to 1xRO peer going into indefinite "Out of Sync" in v1.4.111, even with "overwrite changes" ticked on the RO replica... will it work if I delete and re-create the sync definition for those folders under v1.4.103? Or does the 'experimental' build actually resolve this problem? I would like to try it too - where can we download it?
  2. Well if the data is already synced, then BTsync will only re-index it and compare those indexes with the peer. Only any changed contents will be transferred. So this should not result in a large amount of traffic or time spent to ensure that the replicas are consistent Since 2.0 I've personally been trying alternative software out, because I fear that v1.4.111 of BTSync might have too many bugs (which they most likely won't address for v1.4 anymore) so it seems to make more sense to switch over to a more active project where our minds can be at ease that any discovered bugs will actually be
  3. It really seems to me that the implementation of bloatware and subscription fees became a much higher priority for the developers than the implementation of actually needed/useful features such as this, which would have gradually allowed BTSync to become the very state-of-the-art, widely used/'go-to' tool for simple, flawless and efficient cross-platform syncing capability that is optionally gui-enabled - effectively a bi-directional (multi-peer actually), fully automated/hands-free rsync on steriods - at least that was the very promising experience I had when first trying this software out at
  4. Moving to Syncthing and will deal with it's quirks until they undo this subscription bs in BTsync 2.0 and all the bloat, big mistakes imo
  5. Many thanks for your response RomanZ. It's good to hear that you guys are going to consider the "Restrict only to these peers" feature idea, which would certainly be great if implemented. Unless I misinterpreted you, then I'm also really glad to hear that it's possible to simulate the desired behaviour in the meanwhile by making sure that all the peers simply have the extraneous search options unchecked besides for the predefined hosts. Will give that a try so long and see how it goes
  6. Sure the 'newer' files weren't moved to the .SyncArchive ?
  7. I understand that this project is still in beta phase, but there are a few obvious quirks which should be fixed asap, and I think this is one of them: I have a share where I have explicitly checked only "Use predefined hosts" in the preferences for that share (no DHT, no tracker, no relay, and no LAN search). I specified the desired hosts to sync with, however under the "Devices" tab, that share is showing all peers using that share key (including those which are not part of the explicitly defined list) - such behaviour continues even after restarting the app on all nodes. This can become
  8. I'm quite baffled by the fact that the Web UI is completely disabled without any option to choose otherwise when specifying the shared_folders in a config file. How are we supposed to monitor the precise details about each folder's indexing, sync, traffic, and connected peers status? The logs are very vague on this and mostly just report errors I can understand that web configuration would be disabled as a safety feature to prevent conflicts with the config file, but it should at the very least rather just switch to a read-only means for monitoring the daemon unless a command-line argument