richdotward Posted December 18, 2013 Report Share Posted December 18, 2013 (edited) Anyone understand why item 2 on the below never finishes? 1 and 3 show as synced with a date but 2 is always the same. No data transfer either. One on a raspberry pi the other on ubuntub 13.04 in a datacentre in France. Any ideas? Thanks. Rich Sent from my Nexus 4 using Tapatalk Edited December 18, 2013 by richdotward Quote Link to comment Share on other sites More sharing options...
Harold Feit Posted December 18, 2013 Report Share Posted December 18, 2013 Are they all using 1.2.82?Are any of the files on that problem share in use by any program? Quote Link to comment Share on other sites More sharing options...
richdotward Posted December 19, 2013 Author Report Share Posted December 19, 2013 Yeah both on 1.2.82 below is opposite screen shot on the pi. Nothing using any of the files. Just my backup of apps, docs, pictures, etc. Rich Sent from my Nexus 4 using Tapatalk Quote Link to comment Share on other sites More sharing options...
richdotward Posted December 20, 2013 Author Report Share Posted December 20, 2013 Removed the share. Re added both sides and seems to be working now. As it's in beta a suppose a few issues are to be expected. Nice how it just did a index check and didn't actually redownload it all again. Thanks Rich Sent from my Nexus 4 using Tapatalk Quote Link to comment Share on other sites More sharing options...
andrew_ Posted December 22, 2013 Report Share Posted December 22, 2013 I notice precisely the same symptom. I have a setup with 11 shares on two endpoint systems. Two of them are "stalled" in this manner, always with a tiny amount (up to just a few tens of kB) left to transfer. The first affected share developed this issue several months ago. The amount remaining on stall is always the same, 7.5 kB, and the perspective (upload/download) is different and appropriate depending on which endpoint you're looking at. The share is bidirectional, with lots of content changing on either side. Sync appears to work correctly, however, despite the reported amount remaining to transfer; I'm not noticing any difference between the two folders once it settles, at this point. The other share with this issue just developed it right now as I write. It was also a bidirectional share, with a past static state for several months (no contents changing), and just earlier today with new content on either side (so the result after sync was a merge). It's done its first sync since the content changes, and it's stuck with 31 kB left, yet the sync appears to be complete when examining the corresponding folder on each endpoint. I've not tried removing/recreating the share on BOTH endpoints. But I have tried removing/recreating one of the shares on just one endpoint: after reindexing and without apparently transferring any data, that endpoint settled stuck at the same apparent point, D: 7.5 kB in that case, as it had been before I tried the remove/recreate operation. The endpoints have been upgraded progressively since this past summer, and are presently running 1.2.82. Both shares with the issue were established under older versions of the software, but only now has the symptom presented with the second share as just detailed. The sync clients are run irregularly on both endpoints, one endpoint is a laptop with an irregular connection to the LAN, and periods exist where much change can happen with the contents of the folders forming the shares between runs of the client. I solicit followup/brainstorm reports from any interested forum participants. Yet to consider:What would happen if I copied the secret joined a 3rd node to one of these stuck shares? Would it also get stuck at the same level left to transfer, and in which direction from/to which of the other nodes? What if I removed the shares from both nodes (or all three in item 1 above, if the 3rd node also exhibited the symptom), and recreated the share across all? Are the affected shared folders on each of the endpoints truly in sync? It appears so, but only based on a cursory inspection of file count, file name, file size. Is there a small content descrepancy somewhere? I've not looked at the housekeeping folder .sync-trash. Could the difference be down to filesystem metadata? One endpoint is WinXP, the other is Vista. Perhaps a subtle permissions issue is standing in the way.Cheers. Quote Link to comment Share on other sites More sharing options...
andrew_ Posted December 22, 2013 Report Share Posted December 22, 2013 Followup: The other share with this issue just developed it right now as I write. It was also a bidirectional share, with a past static state for several months (no contents changing), and just earlier today with new content on either side (so the result after sync was a merge). It's done its first sync since the content changes, and it's stuck with 31 kB left, yet the sync appears to be complete when examining the corresponding folder on each endpoint. I've been messing around inside the above referenced share on one of the two endpoints. I've been busy removing old files, renaming and creating new folders, and moving files from previously existing folders into other/new folders within the hierarchy of that share. One large move of files to a different subfolder sparked a 1.1GB re-transfer of data (how incredibly inefficient). Another folder create, followed by file move from a preexisting subfolder into the newly created folder triggered an apparent re-transfer of that file (6.5 MB), at the conclusion of which the share's sync successfully completed with a datestamp. In short, it's no longer stuck, and the situation fixed itself somehow. The other share (stalled w/7.5 kB outstanding), has been that way for months, despite lots of file/folder manipulation similar to the above, and remains in that state. One would need some visibility into the internal state of the client. For instance, what exactly is the client trying to arrange the transfer of when it's showing (D: 7.5 kB)? And so... The inefficient re-transfer of files which were simply getting moved between subfolders of a share sparked me to start this topic. Quote Link to comment Share on other sites More sharing options...
casacota Posted December 22, 2013 Report Share Posted December 22, 2013 Same thing here, with lots of folders not ending, an same issues on multiple machines. Sometimes such things: Other times: In this second case, all machines have 17.5 GB uploaded, the folder size should be the stated 19.5 GB as the original folder is, and no data transfer occurs. But some machines complete the Sync, others not. The behaviour is inconsistent, with many shared folders it appears sometimes on a machine, sometimes on another one. All are sharing the same folders, some in the NAT, others on the WAN side. In the first case the folders on both sides are identical, in the second case obvioulsy not, the last 2 GB are missing. OSs are Windows XP, Macbook and other mixed, version 1.2.82 Quote Link to comment Share on other sites More sharing options...
jwinter Posted January 25, 2014 Report Share Posted January 25, 2014 I have had this problem for months if not a year. I keep hoping that the next release will fix it but it has no effect. Finally I decided to spend some hours trying to get error logs working (I had to conquer how to get into and mess with the system files of my Synology NAS) and submit the bug. I am running version 1.2.82 automatically installed from http://packages.synocommunity.com/ on a pair of Synology NAS boxes. One is an older DS210j (mv6281 ARM processor, 128MB ram), and the other a DS213 (mv6282 ARMv5te 2GHz single processor, 512MB ram). I have one large (40GB) bi-directional share between the two NAS boxes that has this stalling problem. (there are a couple of unidirectional ones that I have been testing to see if they work, and they seem to) I created the debug files with [echo "FFFF" > /usr/local/btsync/var/debug.txt] and after leaving the systems for a couple of hours nothing extra has been written to either of the two files. I have the two large shared folders mapped to separate drives on a windows PC so that I can manually access and modify them. I have tried stopping the syncing, comparing the complete two shared folders with each other using WinMerge.exe and manually deleted or copied over files that didn't sync so that the two folders were identical (except for .SyncID and .SyncIgnore which I have never touched). Then I deleted the all shares and recreated them from scratch and after leaving the system for days (with identical folder systems!), it never completes syncing. Here are screenshots of the stuck state of the two systems:You can see that the box that is supposed to be uploading counts 33496 files, whereas the box that is supposed to be downloading only counts 33380 files, so that 116 files have gone missing somewhere even though winmerge sees and compares them all perfectly (actually winmerge counts 33386 files - I don't know which files are the extra 6!) Could it be a permissions problem? Should I attempt to set all permissions on all files within the folder structure or something? This type of problem is making this package unusable for serious work. Quote Link to comment Share on other sites More sharing options...
AzimutTheUt Posted January 25, 2014 Report Share Posted January 25, 2014 Same problem here on multiple sync... Quote Link to comment Share on other sites More sharing options...
RomanZ Posted January 30, 2014 Report Share Posted January 30, 2014 Hi jwinter, AzimutTheUt, I'll need debug logs to identify what is the root cause of non-syncing.jwinter - you need to put the "debug.txt" file to the folder where btsync binary stays, then you'll get an extended logging. Please see details here. After I get the logs - I can tell you what get stuck (and report to developers for improving app). Thanks. Quote Link to comment Share on other sites More sharing options...
jwinter Posted January 30, 2014 Report Share Posted January 30, 2014 Hi RomanZ, Thanks enormously for getting back. I have very recently emailed this problem to syncapp@bittorrent.com together with links to the sync log files (they were very big even after I compressed them so I put them on dropbox rather than emailing them directly). The request got number #7561 allocated to it (https://syncapp.zendesk.com/requests/7561) so I guess that would be the best source for this information now. Thanks again. Quote Link to comment Share on other sites More sharing options...
RomanZ Posted January 30, 2014 Report Share Posted January 30, 2014 Hi jwinter, Thanks a lot for logs. I'll come up with results analysis when i'm done. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.