SchmitzKatze

Members
  • Content Count

    13
  • Joined

  • Last visited

  • Days Won

    1

About SchmitzKatze

  • Rank
    Member
  1. @RomanZ Does BTsync only write addons to the log or does it save the entire log to my SDD several times per minute?
  2. @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.
  3. 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.
  4. 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?
  5. 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
  6. What is interesting to note is that the client sending sticks at 100% while the client receiving sticks at 0%.
  7. V1.4.75 on all clients. CPU usage on Cubietruck (ARM/Linux) is around 14% when someone connects to the WebUI. After Connections to WebUI are closed, CPU is 1% at max. @JimmyTheSaint What I'd try with your sync-peers-free Synology: add some directories with several thousand files. After indexing finished, quit every connection to WebUI and restart btsync. During restart check the cpu usage to estimate when btsync is up and running again. From my experience, the cpu use at this point should be fairly low. Now connect to the WebUI, cpu shoulde be higher now. Then quit connection to the WebUI and check if the cpu calms down. 1.3.105 didn't calm down, while 1.4.75 does.
  8. Just wanted to say that the problem seems fixed with version 1.4.xx. Thank you!
  9. 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:0It's just a bit from the log, these errors are spread over several places in there. What it going on here?
  10. v1.2.67 Monitoring 9000 files - CPU is about 3-5%@idle. Calling the WebUI, CPU is about 9-11%. Monitoring 0 files, CPU is about 0.3%@idle. v1.3.106 Monitoring 9000 files, CPU is about 10-12%@idle. Calling the WebUI, CPU is about 14-20%. Monitoring 0 files, CPU is about 0.3%@idle. ATM, I don't have the time to check all versions in between. But it's clear that there has been a raise in CPU usage, at least on Linux/ARM. I'm using Lubuntu Server 14.04 (Linaros ARM version of Ubuntu Server, not to be confused with the Ubuntu Desktop LXDE) on a cubietruck. Additionally, I think even with v1.2, CPU usage at idle should be improved. I have several services running like Apache, nginx, MySQL, Prosody, just to name a few, and they do not go above 0.1% CPU when doing nothing. I've read your suggestions from this thread, but it doesn't help in my case. Note: @idle - sync is finished. It doesn't matter if there are any or 5 clients connected.
  11. Unfortunately, I didn't check cpu load on regular basis, so it could be in for a while. Problem is, the repository does not contain any older version, so I can't go back and check when it happend. Is it possible to get older versions? What other information do you need? Btw, the high cpu use is also when no client is connected.
  12. I'm using BitTorrent Sync on Linaro Ubuntu running on a Cubietruck (ARM) for quite some time now. I noticed that BTSync uses considerably more CPU lately than it used to. Months ago, it was like 3%@idle. Right now, it's more like 13-20%@idle. Note: idle=devices are connected, but sync is finished BTSync monitors about 9000 files (there used to be more files, like 15000) spread over 11 folders. I'm using the packages "btsync_1.3.1-1_all.deb" and "btsync-common_1.3.105-1_armhf.deb" installed from either ""http://ppa.launchpad.net/tuxpoldo/btsync/ubuntu" (which one is newer for apt). The log is quite small (<20k) and mainly consists of "Incoming connection from xxx.xxx.xxx.xx:xxxx", like 200 lines. Unfortunately, both PPAs do not provide older versions of BTSync, so I'm unable to downgrade. Is there anyone else experiencing the performance impact on Linux/ARM? What can I do to improve the situation?