sciurius
-
Posts
74 -
Joined
-
Last visited
-
Days Won
6
Posts posted by sciurius
-
-
One of my servers is a BananaPI with Fedora20 and btsync 1.4.93 to share 20GB of data with some 50 other nodes. The data is on a NAS and accessed via Gigabit Ethernet. I haven't encountered problems with performance/resources.
-
My log file contains thousands of entries like
MC[DB85] [3EE6]: failed to verify signature of remote file Install, aborting
It seems to have started after upgrading from 1.4.83 to 1.4.91.
What does this mean?
-
I upgraded my 1.3.x systems to 1.4.x and soon found out that, while 1.3.x never had let me down, 1.4.x proved to be unreliable. Peers got lost, synchs got stuck. Since I used btsync a.o. for backup purposes I did not have another option than downgrading, the hard way, to 1.3.x on my most critical systems.
Currently the 1.3.x systems are whistling nicely. I have one system that it still running 1.4.x and I use it mostly for testing and submitting bug reports.
Unlike many other users I do not have mental problems with the UI. It's the bugs in the functionality that bug me.
1.4.x was meant to be the big official non-beta btsync, or Sync as it is called now, release. But unfortunately it didn't work out that way. After a short while it was demoted to beta again. Personally, I do not understand a release strategy that only releases beta versions. But that has been discussed already.
Once 1.4.x will be as stable as the old 1.3.x I'll probably be more than happy to try again.
-
Try enable DHT on both systems.
-
System A (Synology NAS) w/ btsync 1.3.109.
Share 'Repository' has settings relay server, tracker, LAN, not DHT.
System B (x64 Linux) w/ btsync 1.4.83.
Share 'Repository' has settings relay server, tracker, LAN, not DHT.
The shares are connected and synched. Only these two systems are involved.
On system B, I change the settings to LAN only.
After a while both systems report that there are no peers to connect to.
Restarting btsync on system B will re-establish the connection. I guess a restart on system A would have helped as well.
I think btsync should re-establish the connection after changing the connection properties.
-
As I understand: If you're synching an A-key to a B-key, and you modify a file on the B-system, and then modify the same file on the A-system, the latter file will not be synched from A to B and cause 'out of sync' state.
-
My particular instance of this problem was solved by enabling "Restore modified files to original version" on the receiving system. Apparently, one of the files on the receiving system got modified (or corrupted) and this caused the synch to stall.Sent. Request ID #13482.
Thanks to BitTorrent Sync Support for the final hint.
-
On Synology NAS: /usr/local/btsync/var/sync.log
Don't know about Mac.
-
If btsync were free software, this would be easy to find out. Now we can only guess and try.
Did you try preceding the # with a backslash, e.g.
\#recycle
-
Same thing. I need debug logs from 2 machines that does no sync. And a name of folder and couple of files that does not sync.
Sent. Request ID #13482.
-
System A and B are adjacent to each other and connected via gigabit ethernet (TP-Link switch).
System B is configured Tracker/Relay/LAN.
System A is configured LAN only.
-
Folder on system A is attached to btsync 1.4.82.
A partial copy of the folder on system B is attached read-only to btsync 1.3.109.
System A shows "No peers to receive 104.65 KB." while all peers are connected?
-
Possible workarounds:
- Use RO link instead of key
- Sync data to another, empty folder then move the files you want to be present there into this folder
- Add a new folder, then update the key to RO one.
See the topic above - they are mentioned there.
You can (also) obtain the desired result by using the API 'add_folder' method.
-
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.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 captured logs and made them available several days ago, referred to your name, but until now noone did even look at them.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 threw away 1.4 and restored 1.3, including recreating/restoring of all shares. Now the NAS is behaving normally.
I have one other Linux system that it running 1.4, and it is handling just a few shares. Several of them are in "Sending 100% Remaining: just a few seconds" wait state. For days already. I've send you the log.
-
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".
-
Settings like folder_defaults seem very sensible to have.
-
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?
-
According to the attached screenshot this sync is almost 5TB behind, while the actual size of the folder is 2GB.
-
I sincerely hope so...@sciurius
Sync 1.4 behaves in smarter way. Sometimes it is able to bind "removal" and "creation" event and actually move / rename files. In other cases it can't and moves files to .sync\Archive. However, if it sees that a new file created has the same hash it already has in the archive - it will simply move file from the Archive instead of copying it.
I renamed a share (4000 files) and from that moment btsync is consuming a lot of cpu, almost all memory, while the UI insists that the folder is empty. That has been going on for hours now.
Many other shares are suddenly 'out of sync' or 'receiving' with no progress at all.
It seems that btsync has lost its mind and is now effectively killing my NAS
. -
I know it is now possible to rename a shared folder, but still I wonder why the advised workaround using disconnect/new fails. BTSync is 1.4.75 running on Synology DS413.
I have a folder that is synched readonly. It has a B-key.
I disconnect it. The .sync/ID file is removed from the folder.
I rename the folder to a new name.
I click on the 'link' symbol (you have received a link or a key).
I enter the B-key.
I select the (renamed) folder.
I get a warning that the folder is not empty and files may be overwritten. I click [OK].
The folder is connoected to btsync but gets a new A-key.
What am I doing wrong?
-
BTSync cannot know that a folder has been renamend. All it sees is that a folder has disappeared, and another folder appeared. It then acts accordingly.
-
Yes, with the BitTorrent Sync API.
curl 'http://admin:password@localhost:8888/api?method=get_folders'
-
No, the other system is a x86_64 desktop.As i understand - first system is NAS, and second system is NAS too?
The DS413 has 1.067 GHz Dual Core-processor and 1 GB DDR3 RAM. It should be capable of handling this btsync load with less than 5% CPU.CPU usage depends from: CPU architecture, number of cores, number of supported instructions (SSE, AES) etc.
.
Out Of Sync - No Peers Online
in Sync Troubleshooting
Posted
I get this situation often even with small directories, less than 100 of small files.
It occurs to me that for backup purposes, "Restore modified files to original version" should always be enabled by default since the backup side is not supposed to have local modifications.