stanha

Members
  • Content Count

    141
  • Joined

  • Last visited

  • Days Won

    3

About stanha

  • Rank
    Advanced Member
  1. I am still trying to recover 1.3.109 related stuff. Some shares got really screwed up because of new .sync subfolder and so I had to copy things back to the main share's folder and I guess some things I copied changed the mtime on some files. So, now I have one folder with weird behavior. Since some of my mod-times on some files were of now, then they restart syncing them and create the filename.Conflict files. If I try to touch those files, then depending on how I touch them (-m only) option, they either reupload the same file adding .Conflict to file name, or upload AND download them, again
  2. I just removed the BTSync via control panel (Win7). Then moved all the files in AppData\Roaming\BitTorrent Sync to the backup folder. Then removed all the .sync folders. Then added 2 of my main shares and it looks like at least one of the nodes does show its sync state correctly (does not show the entire share to be uploaded to it), which seems like some progress. Unfortunately, there are only 3 nodes on line at the moment and the other 2 still show as being utterly empty, which is false as they are fully synced. So, I guess we have to wait and see what happens when all the regular nodes come
  3. Are you sure about these instructions?Let's see if I understand it correctly. 1) I need to physically delete the BTSync binary from Program Files dir (Win 7). 2) I have to wipe out everything from AppData\Roaming\BitTorrent Sync, including the databases 3) Remove all the .sync folders from all the shares. Do you know why, by any chance? Do .sync folders interfere with 1.3.109? Right now I have 1.3.109 running except all the nodes show as empty while they are all synced. That is my main problem, at the moment at least. I hope someone has an "authoritative" instructions on this.
  4. I'd like to see the precise instructions on how to recover 1.3.109 and have all my nodes showing the sync state they did before me trying to install 1.4.72. As far as the difference between "beta", "alpha" and what constitutes development, are you an authorized spokesman for BT? As far as I can see, switching to totally new UI constitutes a MAJOR development effort that has and will continue to have the most profound impact. And once people begin to comprehend what actually happened, how many of them will be crying to get back to 1.3.109? In my opinion, the 1.4.72 release should be pulled imme
  5. First of all, on beta, you don't do ANY development. Beta, to the best of my understanding is purely a bug-fix release. All the development if frozen in beta.So, to call this "beta" is misleading the potential users. It is not even a proper alpha, even though in alpha some minor development thins are acceptable. The problem is that not many people will be willing to download and try the alpha releases. But nearly everyone would be willing to download beta in hope that it is something close to the final release. But BTSync is not even close to the final release. It is FULL of most fundamental b
  6. I am not going to comment on UI which is not even a disaster and lack of basic understanding of UI as such and how do you make it really better, more useful, more informative, easier to navigate with less mouse clicks and so on, and it is not even pathetic from the programming standpoint. It isn't even laughable. It is utter disaster, total and complete. But the question I have is the precise instructions to get back to 1.3.109. After struggling for some time and finally able to reinstall 1.3.109 what I see is my main share showing ALL the nodes as empty, ie needing the upload of the entire sh
  7. As of 1.3.106 (Win7 r/w node) following weirdness happens: The R/O nodes upload the newer version of files on R/W nodes. Here's the scenario: I had to adjust my box's clock into the future because there is one node that shows +1 day and +1 hr. time in respect to the r/w node. So, in order to give him the newer version of the main files, I had to exit BTSync, adjust my comp clock and then restart, so that he could sync. Meanwhile, there was one file updated on the r/w node and it was not synced yet before I had adjusted the clock forward by 1d:1hr. Now, since BTSync queues the files and probabl
  8. I also observe this issue constantly. After a couple of hours of BTSync running I see a number of r/o nodes that are usually always present on that share, drop from about 10 to 2 or 3. But when I restart BTSync the number of nodes goes back to normal. We are talking about 1.3.106 on win7.
  9. What is interesting in this case is that timediff does not matter. No matter what r/w node's time is set to, as soon as BTSync is started, it begins to try to re-upload the files. This means to me that we are past the timediff checks and are placed in some queue to upload, which, in turn, probably implies that the reason the same files keep trying to be uploaded is that on the receiving end (r/o nodes), sync temp files are present, which could be caused, for example, by interrupted upload for whatever reason. This means that the sync temp files has to either time out or deleted after N attempt
  10. I am seeing a couple of nodes to which the r/w node keeps trying to upload several files, and for some of those files it even shows some upload speed, like they are actually being sent to those nodes. But the process keeps repeating every minute or so, trying to upload the same exact files. This has been going on for days. But this does not happen with other nodes that also show to be incomplete. Actually, by now, about 80% of all the nodes on one of the main share keep showing the incomplete state.
  11. What happened to "Restore modified files to original version" on 1.3.105 Linux GUI?
  12. I do not have debug logs from the node that is stuck. This is a general public situation and I have no clue about that node. I can provide you logs from the r/w node and from the 3rd (r/o) node that is sitting right now trying to complete the upload. Btw, is debug.txt (on Linux Ubuntu) being sampled in real time or I have to restart BTSync on that r/o node? Because if I have to restart, the state of the node will change as far as I can see. Let me know if those logs that I can provide might be useful to you. Else, I have no time to waste on this. Thanx.
  13. OK guys. This is beginning to get on my nerves. BTSync is FULL of bugs and it is probably the most unreliable and inconsistent program I have ever seen. And the problem with it is this: I have provided quite a lot of proposals to BTSync with specific suggestions, analysis of the MOST critical and literally vital issues and all of it was ignored. In some cases, they even promised to take care of one of the nastiest design flaws related to timediff error, which is clearly a flaw in design in my opinion. But ALL of it was simply ignored, and its been months now since these issues were raised. And
  14. There is an interesting aspect to this that may shed some light on it. There is the third node on the same share and I know for fact that node works perfectly well and the r/w node has that node on its predefined host list. Now, interestingly enough, the node that is "stuck" and does not want to continue finishing the download as seen from the r/w node does not seem to complete its download via 3rd node either. When I look at that share via that third node it definitely shows the amount left to upload of about 16 megs out of total of 180 megs and it does not show any transfer in progress as sh