stanha

Yes, I confirm this on Windows. The transfer speed as shown in new "status bar" (centered at the bottom of main screen) shows pretty much exactly the 2 times more speed then the actual file transfer speed as seen during big files' transfers in Transfers tab next to the file being transferred, which seems to be showing the correct transfer speed.

Hi RomanZ, I just sent you PM. I've never done it before, so, I hope it worked.

I had 1.3.80 crash several times. Here are 3 core dumps, that could not be sent automatically: Removed.

And once they are at it, they can easily add another column to Devices tab to display a device message, and, just like it is done with (i) tooltip in Transfers tab, can can easily put up a message box to display a message from that device. Because I keep seeing users with problems every day and this is a general public situation, so I have no idea who they are. A couple of them display the incomplete upload size of 30 to 50k even though the (i) tooltip shows that they still have to download a 400-500k file. I'd like to communicate to them and ask what have they done to those files so they are not receiving them. The sending r/w node keeps trying to send them the missing file(s), but nothing seems to transfer.

If I recall correctly, BTSync uses uTorrent compatible tracker algorithms. Q: Is it possible to add non-BT trackers, that are used with regular torrents, regardless of whether BT tracker option is enabled by "Use tracker server"? If not, are there any plans to implement such a feature?

I hope full path will be added to Devices tab. This was my primary concern. But at least we are moving in the right direction.

I do not see the full path column.

Can predefined host be used as a tracker for the shares it does not have? Could it be considered a general purpose tracker?

I had a crash on 1.3.77/Win. Crash dump: Removed.

"Time does not go back"? - False The design assumption that "time does not go back" is groundless. The O/S or anything, for that matter, does not and can not prevent you from setting your clock time to anything you wish for whatever reasons you have. For example, you may decide to set your clock YEARS back in order to touch some files to update their time stamps. The computer clock time is what its clock says. Nothing more, nothing less. No assumption may be made that "time can not possibly change this way, logically speaking". Because, reality speaking, it can. Update #1 Btw, one example of it is DLS time adjustment when clock automatically goes back 1 hr., at least on Windows.

Today was a DLS adjustment automatically performed by Windows adding 1hr to the clock time. As a result, 1 node that used to sync without problems up to yesterday, now shows in my log as though I am +2 hrs. off of him and now his node displays the dimediff error msg. And it also shows that the remaining amount to be uploaded to him is the entire share, even though he is fully synced. Interestingly enough, there are several more nodes on that share and they do not display the timediff error msg. and show that they are fully synced.

File size and transfer progress in Transfer tab No point in this.

Well, it is hard to say, really. Basically, that guy started uploading a bunch of stuff, then I started to see a timediff error for his node for several hours. Then he was gone. When I got back to my box, I saw him again, but without timediff error and I saw him continue to transfer lots of stuff. When he stopped the transfers, but did not quite complete it all, it seems, I kept seeing these tooltip messages appearing as though he was still uploading, while he was not, and it continued even after he had left the share. Then he came back again and continued to upload more stuff. Then he left again. And now I am not seeing those messages popping up continuously. That is ALL I can tell you. [as I said, I have all the compassion for you ] Well, it is a general public situation. I have no clue who he is and the only way I can contact him is through my Device name, and that'll work only if he ever looks at it and ht is not using BTSync on his headeless server box under the table in his kitchen. Update #1 Btw, are you saying that this issue is fixed in 1.3? I'd like to get to 1.3, but ONLY if you guys give me an option to display the folders in Device name the old way. I, personally, do not like that new idea of displaying some folders as the last element on the path and others as full path. It seems to me this can be done by simply adding a new column to Devices tab and leaving the full path display just the way it was before. There is a number of ways to do it, such as Win explorer properties where you can simply click on a checkmark to enable/disable some column in display. Actually, I would not like to even see that column that only shows me the last element on that path and I wish I could disable it if you decide to go that way. Well, I could simply drag that column to far right. That would be OK with me. Update #2 Hey, I like your idea of packing a bunch of small files, such as little images, into a single torrent. That really improves the overall performance. I'd probably pack not less than 1-4 megs of stuff into a single torrent, unless there is nothing left to transfer. Because I still see in some medium size files (30 to 200 k) that transfer rate drops down by the factor of 3 approx. That means to me there is still a lot of overhead somewhere and small files are not quite processed in bulk and in bigger chunks. Update #3 Well, I see that guy that was doing uploads back on line and he brought another 700 megs of stuff to upload and I can see those tooltip messages returning, except they look appropriate now. In case you want me to tell him something in Devices tab, that would be fine with me. Who knows, he might even read it.

Update #1 I decided to try to delete that share that keeps displaying the tooltip, stop the sync, remove all those files about which the message is displayed and then recreate the same share with the same key. I though it might have something to do with wrong file date stamps when the other nodes' time was in timediff error zone. After it reindexed that share, it still keeps displaying the same message about "finished downloading", but about all the files in the next subfolder, and the funny part of it, the other node isn't even on line. So, I am at a loss what to do and what does it mean. Is it a default behavior to keep going through all the files in the share and keep displaying that message every few seconds about each different file in a share? Is it a "normal" behavior?

(This is re 1.2.92 version on Win) I keep getting the notifications in the BTSync's windows taskbar icon saying: "file xxx has finished downloading". But that file was not actually transferred and it already exists on the destination node (both nodes r/w). And this is a loop that never ends, going through the files in Images subfolder. Also, BTSync keeps showing that there is still 1.1 megs left to be downloaded even though both nodes are r/w and there is nothing in .SyncIgnore that I know of that should prevent the downloads. No file modifications or any other alterations have been done on the destination node. This (uploading) node had a timediff problem yesterday and so he could not compete the upload at that time. But now it is fine in terms of timediff.

Yes, I also seen the tooltip left hovering and not disappearing properly when you move around with cursor.

I think I got something that should tell someone who understands this why am I seeing a node (r/w) that does not sync with me while it shows that we have some files to exchange. Here is a few bits from the log: (Anybody knows what is the meaning of "...but failed to get mtime 123"?) (we are talking about the node "quadriped": [2014-03-28 02:00:01.059] Got id message from peer quadriped (0035EAC9E9A070579DD67CD6C838330AB6CFB906) 1.2.82]) ... [2014-03-28 01:59:57.814] Peer 2: 77.250.101.18:31781 0035EAC9E9A070579DD67CD6C838330AB6CFB906 [2014-03-28 01:59:57.814] Peer 2: local IP 192.168.2.236:31781 [2014-03-28 01:59:57.814] Got list of 1 peers from 54.225.100.8:3000 [2014-03-28 01:59:57.830] Got list of 2 peers from 54.225.92.50:3000 ... [2014-03-28 01:59:58.017] Got ping (broadcast: 0) from peer 77.250.101.18:31781 (0035EAC9E9A070579DD67CD6C838330AB6CFB906) for share E6077B97333D5EE14F2C1D370DE8ACAAFE2B0113 [2014-03-28 01:59:58.017] Found peer for folder \\?\R:\Sync\Osho_Books_Interactive 0035EAC9E9A070579DD67CD6C838330AB6CFB906 77.250.101.18:31781 direct:1 ... [2014-03-28 02:00:00.357] Going to sync state with peer 77.250.101.18:31781 (0035EAC9E9A070579DD67CD6C838330AB6CFB906) [2014-03-28 02:00:00.357] LoadTorrent: file \\?\R:\Sync\Osho_Books_Interactive\Pdf\jewish\The Mustard Seed - Commentaries on the Gospel of Thomas -216p.pdf exists, but failed to get mtime 123 ... [2014-03-28 01:59:58.017] Send ping to peer (0035EAC9E9A070579DD67CD6C838330AB6CFB906) for share E6077B97333D5EE14F2C1D370DE8ACAAFE2B0113: [2014-03-28 01:59:58.017] ping 77.250.101.18:31781 directly ... [2014-03-28 02:00:01.059] Got id message from peer quadriped (0035EAC9E9A070579DD67CD6C838330AB6CFB906) 1.2.82 [2014-03-28 02:00:01.059] Merge: processing root message, remote hash 011B69A197B9DC53F5A4204DFEA0F1EC35A198DF, timediff: 7 [2014-03-28 02:00:01.059] Merge: sending get_have_pieces, prevhash: 2B63ADB6F96EF9722124C4806549D68A990450C9 [2014-03-28 02:00:01.200] Merge: processing have_pieces message [2014-03-28 02:00:01.200] State sync finished for folder \\?\R:\Sync\Osho_Books_Interactive What does this log tell you if anything?

And that is why I am jealous!!!

Wow!!! I am impressed. I don't remember the last time when I have seen such a precise and laconic answer.

You are right again... I am jealous!!! We are good now. Thanks a bunch and I do indeed appreciate your work.

It never goes above 1k. All I have ever seen in it is 3-4 lines of text max. I do not see log_size in Preferences - Advanced tab. We are talking about 1.2.92 version on Windows. I tried to deinstall BTSync from Win control panel and then reinstall it again. Did not help. Then I restarted the box. Did not help. Update #1 I wonder if this has something to do with 1.3.67 installation and that "rotating log" idea. Could it be that something in the registry that got messed up permanently? Would be interesting to know under which conditions log is being automatically removed. Because it is precisely removed and not truncated to 0 size as Win explorer shows.

I just started seeing that sync.log on Win version BTSync 1.2.92 is automatically deleted every few seconds and then recreated, and so it cycles forever, deleting and recreating it. When you turn logging on, it happens much faster, 2-3 times/sec. So, the overall impression is that it is deleted after a certain amount of text gets in. A couple of times I saw a 3-4 lines of text in it and those were ping log entries.

BTSync 1.3.67 display locks up All of a sudden, I could no longer select any other device then the one that was currently selected. Furthermore, right clicking on BTSync icon in Win task bar would screw up the whole windows desktop. Things would go black color, task manager would be surrounded by the black color frame of about 10 pix in size and on the desktop, instead of Explorer windows I would see black holes. Clicking on the BTSync icon on the taskbar would no longer open the BTSync window.

RomanZ, I have all the compassion for you and I do realize that the amount of information you have to deal with is overbearing, to say the list. OK, I'll try to see what I can do. Proposal Implement the standard program menu and on View menu add a checkmark "Display folders as full path" instead of always showing only the last element on the path and calling it a folder. Sorry, but I can not make it shorter than this.

File does not fully sync I have noticed that some r/o nodes were at one point fully synced but then started to show various amounts to be still uploaded. Those amounts are usually relatively small, between 30 to 500 k. Since installing 1.3.67 with this new tool tip showing which files are queued to be transferred, now I can see exactly what is the problem with those nodes. Just now I saw one node that was showing 31k still to be uploaded. I turns out that one particular file was still to be uploaded. Its file size is 500k or so. So, I modified that file to see what happens. At that time there were 7 nodes on line. All of them got updated normally, but that particular node would also show that the size to be uploaded was 500k, but when it was done syncing, it would again show the same 31k still to be uploaded. Question: is it possible for the file to resync, but only sync those blocks that had a hash indicating they were updated? If I recall correctly, I remember that someone said that files of less than 4 megs (do not remember the exact number) were being synced as a whole, but files larger in size would only sync those blocks that were changed.