• Content Count

  • Joined

  • Last visited

About kratochviljan

  • Rank

Profile Information

  • Gender
    Not Telling
  • Location
  1. Thank you very much for the paid version 2.0. It should probably be a gift for all of us for testing and endlessly reporting while helping to bugfix earlier versions. Lot of us (users from this forum) spend days with testing and bug fixing, installing lab environments and so on. Why ? Probably because we all want to have excellent sync app. But when they finally looked promising, bang, paid version. Do you think that we've all been doing because we finally lived to see the paid version? I'm personally totally disappointed and lost of confidence. You used a large group of people to he
  2. We can celebrate today, because today is it exactly two years since first wish on this topic was written to the forum. We can celebrate today, because today is it exactly two years since first wish on this topic was written to the forum.
  3. And one serious issue in "listening port" settings. Port settings under shared folder in "Use predefined host" settings has absolutely no effect to communication between peers. As you can see on this screenshot from my test environment, there is port 11111 set for both peers. But all communication between peers going thru ports 4096 which is set under global preferences in "Listening port:" field. I made few experiments with those settings and my result is, that only matters on global Listening port. You can type whatever you like at shared folder setting because this settings is ignored.
  4. One cosmetic issue in webui: (Menu is rolling under the upper bar)
  5. At least is not tested, and as you know, version 1.4 still have many reported bugs outside this one. (listening port, predefined hosts, UPnP port mapping, many reported UI problems...) I think that there is many lucky users that did not update their environments to 1.4 and for all of them this patch should be extremely helpful, because this issue was one from the essential one.
  6. This is great news! I hope, that the reason why was newer files overwriten is known. Would it be possible to release patch for this bug for "old" version of BTSync client 1.3.109 ? Thus for last usable version in production. Existing 1.4.x version is not usable in meantime. Thank you, anyway.
  7. @RomanZ Yes, of course I'm. That's why I already set up my test environment and this is only option. I'm using BTSync for lot of data which I'd like to keep nor lose them. Rely only on your testing failed in the past. No offense, keep things moving, I'm ready for testing.
  8. No connections can be established between peers in those situations: - Use UPnP port mapping is unchecked on all or some peers - Predefined hosts are used in sync folder preferences INSERT:> I set up test enviroment - 3VM / 3 peers running Windows 7 x64 with latest version of BTSync. All peers are on the same virtual LAN segment with common address scheme. LAN:, SYNC1:, SYNC2:, SYNC3: In situation that there is one folder synced between all of the peers and I change option "UPnP port mapping" on all or on some peers BTSync falls a
  9. Hmmm, somehow, still nothing happens. Perhaps it would be better to first have functional sync engine and then to polish GUI.
  10. Maybe it will be best solution to have web based gui like on Linux and BTSync should run in background as service without desktop control. At least it could consolidate control among different platforms (windows / linux). I think that separate web gui (linux like) is the best way. Or maybe two separate versions, if you guys would like to maintain one more version, desktop interactive and background service with web gui. I know, that some users should prefer present desktop gui, but for servers is there a gap. Thanks for even better BTSync.
  11. Yes, please. This feature can help me much. I solve this almost daily. Each directory structure change indicate complete retransfer of all concerned files. I can not agree with ChrisH. All hashes are already there, there is no need to compute another ones. I think, that there is only need to change "detection" mechanism between file/dir was deleted and file/dir was moved in synced structure. Like today, I made change in directory structure of 100 GB in size. I move all directory in root folder to one folder deeper, which has consequence in complete retransmit of 100GB of data and all struc
  12. Yes, it was running on both sides. I edited photos directly in directory which was synchronized in real time, I mean when I edited photos - under my hands and it works well. (there is one another issue with file locks - file which is synchronized by btsync is locked for writing so this can not be saved / modified during sync) But due to the speed of my DSL line I finish all of my work on photos and btsync was still running. I thing it could run for couple of hours. In this time period remote server has been restarted and after the reboot btsync start to synchronize all files from this director
  13. Anything new to this "wish" ? We are still waiting for native BTSync service. I hope that we will see the light or at least some progress.
  14. I have exactly the same issue. Newer files was replaced by older ones. I edited the photos, there were around 300, I spent over about 3 hours. At night, ran a full sync, a total of about 4 Gig of data. Unfortunately the opposite direction. All of my edited photos was again overwritten by originals. I do not have detailed debug log, of course, but from the History there is clearly visible, that sync was running in opposite direction. I was already reported similar issue - It seeams to me that the bug is stil th