[V1.4.75] Hanging At Sending/receiving 100%/0%

[SchmitzKatze]

For reasons unknown to me, BitTorrent Sync sometimes gets into a state where both clients think they are about to sync but in fact won't sync any data for several hours.
I usually work around this by manually copying the newer data over the older data if it is a lot of data. If it's just some files that hang syncing, I simply rename them and wait until sync get's over it.
Restarting BitTorrent Sync does not fix it.
I had this error since I started using BitTorrent Sync last year. Today, I had some time digging through the log files and found this:

[2014-09-11 00:31:22] FC[831F]: file updated - processing file \\?\C:\Users\USERPROFILE\Projects\BA-Aufnahmen\FUB Atrium\render_out\LF\peaks\LF_dc_fft_FUB_Atrium_IR_2,94mK_-00dB.wav.reapeaks t:1409853191 s:154[2014-09-11 00:31:22] SF[831F]: Max number of torrents reached (139)[2014-09-11 00:31:22] ScheduledTask:ConnectMorePeers invoked:timer reason:UnloadInactiveTorrents - torrent wants connection[2014-09-11 00:31:22] SF[831F]: Torrent \\?\C:\Users\USERPROFILE\Projects\BA-Aufnahmen\DFOB\render_out\IRs\Analysis\dc_fft_DFOB_IRs_5,75m8_-33dB.wav.png status:137 error:<NULL> meta:1 conns:0 io:0[2014-09-11 00:31:22] SF[831F]: Torrent \\?\C:\Users\USERPROFILE\Projects\BA-Aufnahmen\DFOB\render_out\IRs\Analysis\dc_fft_DFOB_IRs_5,75m8_-30dB.wav.png status:137 error:<NULL> meta:1 conns:0 io:0[2014-09-11 00:31:22] SF[831F]: Torrent \\?\C:\Users\USERPROFILE\Projects\BA-Aufnahmen\DFOB\render_out\IRs\Analysis\dc_fft_DFOB_IRs_5,75m8_-27dB.wav.png status:137 error:<NULL> meta:1 conns:0 io:0[2014-09-11 00:31:22] SF[831F]: Torrent \\?\C:\Users\USERPROFILE\Projects\BA-Aufnahmen\DFOB\render_out\IRs\Analysis\dc_fft_DFOB_IRs_5,75m8_-24dB.wav.png status:137 error:<NULL> meta:1 conns:0 io:0

It's just a bit from the log, these errors are spread over several places in there.

What it going on here?

[sciurius]

I seem to have the same situation since I upgraded to 1.4.75. All syncs seem to be stuck with "Sending/Receiving 100%". What is worse, DATA DOES NOT GET SYNCHED! Some files that did get synched recently get a bogus timestamp op Jan 1, 1970.

Currently btsync is consuming 50% CPU, 114% of the available (1GB) memory and doesn't synch. The end of a reliable tool?

[SchmitzKatze]

What is interesting to note is that the client sending sticks at 100% while the client receiving sticks at 0%.

[sciurius]

Since my major share system (Synology NAS) went bezerk after upgrading to 1.4, I needed to downgrade it to 1.3. This involved wiping all btsync stuff, recreating the shares, restore from backups, and so on.

The share system is now stable again and happily sharing the 100.000+ documents just like it did before the 1.4 upgrade. I will no longer complain about the 5% CPU time that btsync 1.3.109 takes.

I do not know what went wrong during or after the 1.4 upgrade, if anything did go wrong at all. Stories from other users lead me to believe that 1.4 needs some more time and efforts to mature.

I still have 1.4 running on another Linux box to experiment with. That is, if it ever gets past the "remaining: few seconds".

[SchmitzKatze]

And as I already wrote, this stuck sync thing is something I experienced several times over the last year. So you are likely to have some flashbacks again over the next weeks. It happened to me with all versions ... but maybe you are more in luck than me

[Gunsight]

I seem to have the same situation since I upgraded to 1.4.75. All syncs seem to be stuck with "Sending/Receiving 100%". What is worse, DATA DOES NOT GET SYNCHED! Some files that did get synched recently get a bogus timestamp op Jan 1, 1970.

Currently btsync is consuming 50% CPU, 114% of the available (1GB) memory and doesn't synch. The end of a reliable tool?

I have same problem

Any solution ?

Have BTsync on my NAS and on my seedbox. 

Sync stops all the time .....

 

Anders

[ftjn740]

I seem to have the same situation since I upgraded to 1.4.75. All syncs seem to be stuck with "Sending/Receiving 100%". What is worse, DATA DOES NOT GET SYNCHED! Some files that did get synched recently get a bogus timestamp op Jan 1, 1970.

Currently btsync is consuming 50% CPU, 114% of the available (1GB) memory and doesn't synch. The end of a reliable tool?

 

Exactly same. Looks 1.4.xx does have serious issue.

I have same problem

Any solution ?

Have BTsync on my NAS and on my seedbox. 

Sync stops all the time .....

 

Anders

Same issue with me.

[modr]

I've got the same issue, but I'm of the opinion, that this issue already exist since 1.3,xxx, but I'm not too sure as I've gott one Server and multiple clients and I'm not sure when I updated which client.

 

The difficulty I'v got is that my clients are location wise sperad across hundreds of miles. Therefore, I cannot simply  access them to copy files from across.

 

Any other option to manually resolve the these issues?

[SchmitzKatze]

Rename the files that BTSync got stuck syncing at to something like file.doc.bak. Wait for file.doc to arrive. Check if both are the same and if delete file.doc.bak. Otherwise, find out which is the new one and delete the old file.

Unfortunately, BTSync may stuck syncing several thousand files. This way, it's best to remove the folders from BTSync and start all over again.

Could you guys look up your log files and look for something suspicious?

I posted some log details in my first post. Maybe someone from the tech team could look at it?

[daishi4u]

I kept 1.4.75 on my nas and downgraded to 1.3.109 on my two windows machines. Had the same problem, BUT 1.3.109 at least tells you what files are currently syncing per share so by that you can figure out which ones are getting stuck without looking at log files. I simply cut the files that are stuck and paste them to a place that isn't being synced and wait for sync to say it's done syncing. Then I cut and paste the files back where they belong and it ends up syncing just fine.

Sent from my SCH-S738C using Tapatalk

[SchmitzKatze]

If you want to see what files are being "synced" with the UI from v1.4.xx, activate the column "Peers" and then click on it. This brings up a window showing you what devices are in sync and what devices aren't. You can click on a device that isn't in sync. This will open a list of files that need to be synced.

[ftjn740]

I run V1.4.75 On my NAS (WD MBL), and I just use it to sync .jpg and mp4 file between my Android phones. Always happen this issue. And NAS sync response very slow for any new added file on Android phone, usually 3+ days, sometimes never response. Such issue never happened on 1.3.xx

 

I think BT team should check this issues carefully, since there is many users happend to have same issue according to this forum.

[vawaver]

I have similar problem.

PC to PC  - both clients 1.4.75 - Windows 8.1

After restarting client my synchronization reset from 25% back to 0% and I do not know why.

 

[GusBricker]

I also have this issue on 1.4.75. Have 2 OSX clients and 1 Linux client. Quiet frustrating that a >v1.0 release can be this unstable and broken. 

[GreatMarko]

Quiet frustrating that a >v1.0 release can be this unstable and broken. 

 

Please do bear in mind that Sync is currently in "beta". As with any software title, simply having a version number >1.0, doesn't automatically mean that it's a "stable" release!

[ftjn740]

Should be the issue on NAS app. nothing related with Android app. Before I upgrade nas APP to 1.4, everything fine even Android app upgraded to 1.4.

I kept 1.4.75 on my nas and downgraded to 1.3.109 on my two windows machines. Had the same problem, BUT 1.3.109 at least tells you what files are currently syncing per share so by that you can figure out which ones are getting stuck without looking at log files. I simply cut the files that are stuck and paste them to a place that isn't being synced and wait for sync to say it's done syncing. Then I cut and paste the files back where they belong and it ends up syncing just fine.

Sent from my SCH-S738C using Tapatalk

it is a serious issue that cannot explain with such execuse.

Please do bear in mind that Sync is currently in "beta". As with any software title, simply having a version number >1.0, doesn't automatically mean that it's a "stable" release!

[colinabroad]

This is interesting to see as a new topic for 1.4.75 - I have previously reported this issue on this forum and to 'the team' via feedback since beginning to use this software about 6 months ago.  I have yet to receive a reply from my last email in to the team, but I have simply been told that a file is 'stuck' and I need to delete .sync files to unstick them.  I have also previously used the useful feature in 1.3.109 to find errant files and 'deal' with them, either by renaming them, or by opening them and resaving as others have reported in this thread.  However, this does not fix the underlying problem that 'the team' seem to have missed/ignored/disbelieve.  It is the program that is causing the issues here, NOT the users.  We ALL accept that this is a beta version - but some acknowledgement of THIS particular issue that HAS been around for several versions (since 1.3.98 for sure)  would not go amiss IMHO.  Asking ALL users to check their log files to find 'errant' files is not really a solution.  Without the aid of a user manual it is tricky to find 'features' - especially having got used to where things are in 1.3.xx only to discover they have either moved or are missing from 1.4.xx  I had thought that this piece of software was going to solve not only MY needs for backup and synchronicity across several devices but millions of other people as well.  It sadly seems now that this is not going to be the case.  I continue to use the software as it does APPEAR to be working, but the (lack of) error reporting in the GUI along with what appears to be a management decision to radically degrade (IMO) the usability of the software is not good.  The negative vibes I am getting in this forum from the response to so many peoples posts is putting me right off this 'solution' - such a shame, as it was beginning to look like a viable alternative to the likes of dropbox, google drive and one drive!

[RomanZ]

Hi all,

 

The issue is not as simple to catch. It never reproduces in lab "on demand", has multiple root causes, so technically, it can be fixed several times. 

 

I would ask users who suffer the issue supply us with debug logs - so we'll try to find out what happens and fix it. Please send your logs to syncapp@bittorrent.com with reference to this topic and your scenario described.

[SchmitzKatze]

@RomanZ

The entire log is gone. As the error is persistent to restarting BTSync, I think the hard part is to catch the log where the bug occurs for the first time in a shared folder. It's likely that after restarting BTSync you only have log entries that deal with the consequences and not with the root of this bug.

Anyway, maybe the snippet from my log (see my first post) is of any use? The files mentioned are exactly the files the shared folder got stuck at.

[erenoglu]

I have this problem as well. I had 1.4.75 on two client systems and 1.3.x on a VPS with encrypted remote. The Client 1 and Vps synced fine, but the Client2 this morning did not get the changes from the others (was off since 2-3 days).

 

so I tried to upgrade the VPS one to 1.4 as well and ended up in this situation. The first error I saw was "out of sync", after some re-starts, it is now stuck at "sending 100% few seconds remaining" since some hours.

[RomanZ]

@SchmitzKatze

The log piece is not enough. It already shows the results of a bug, not the bug itself. Though, what is the problem to catch it in the log? You can extend log to rather big size by setting "log_size" advanced preference to, say 1000 (~1Gb x 2 log size). And, of course, collecting before Sync is restarted.

[sciurius]

Please do bear in mind that Sync is currently in "beta". As with any software title, simply having a version number >1.0, doesn't automatically mean that it's a "stable" release!

I'm sorry to disappoint you, but BitTorrent Sync left the beta phase with the 1.4 release. Up to 1.3, it *was* marked as beta. Starting 1.4, the beta notice was removed from the (new) site. The downloads point to 'stable' folders, and so on.

I would ask users who suffer the issue supply us with debug logs - so we'll try to find out what happens and fix it. Please send your logs to syncapp@bittorrent.com with reference to this topic and your scenario described.

I captured logs and made them available several days ago, referred to your name, but until now noone did even look at them.

[SchmitzKatze]

@RomanZ

Does BTsync only write addons to the log or does it save the entire log to my SDD several times per minute?

[RomanZ]

@sciurius

I see your Key for the logs in our ticketing system submitted on Saturday, thank you for sharing. We have really big number of issues reported these days so it takes a while to analyze logs and respond to everyone. We'll look into your logs and do our best to determine the root cause. We appreciate your patience. 

 

@SchmitzKatze

Yep, it only adds new content (otherwise, it would be too heavy too keep such big log in memory).

[GreatMarko]

I'm sorry to disappoint you, but BitTorrent Sync left the beta phase with the 1.4 release. Up to 1.3, it *was* marked as beta. Starting 1.4, the beta notice was removed from the (new) site. The downloads point to 'stable' folders, and so on.

 

sciurius, please see Introducing Sync 1.4 (which is linked to directly from the main website http://www.bittorrent.com/sync/ right below the main download button) and note the very first line of that article: "New in Sync 1.4 Beta"

 

Whilst the team are going to look at making this clearer, the fact of that matter is that Sync remains in beta at this time.