richdotward

Never Seems To Finish

Recommended Posts

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.

ara4e8as.jpg

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 by richdotward

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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:

  1. 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?
  2. 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?
  3. 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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Same thing here, with lots of folders not ending, an same issues on multiple machines. Sometimes such things:

 

nosync.jpg

 

Other times:noend.jpg

 

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

Share this post


Link to post
Share on other sites
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:

screenshot.1.png

screenshot.2.png

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.