RomanZ

Administrators
 View Profile  See their activity

  • Posts

    3,588

  • Joined

  • Last visited

 Content Type 

Everything posted by RomanZ

  1. RomanZ
    @JimmyTheSaint Let's take a look what is BTSync doing to consume these 11-13% when idle. Can you please collect the debug log, send it to us together with the time mark when BTSync became idle? It should not consume that much CPU to my understanding, so I'd to understand what is happening.
  2. RomanZ
    Gerard, Thanks for sharing this information with the community!
  3. RomanZ
    @Jo-Lion Well, that's a tricky situation. BTSync has no function to revoke secret from unwanted peers: once you've got a secret, you have access. The most simple way is to just change the secret on devices that you can access. In this case your ex-colleague won't see updated files and won't be able to change them - but still will retain the latest copy she managed to sync. Deleting files from your peer won't help: Sync does not just deletes files, it moves them to hidden .SyncArchive folder, so she'll still be able to access them.
  4. RomanZ
    @b0rman I suggest that iNotify is not working for your CentOS. Which version of glibc is installed on your CentOS? 2.3 does not support iNotify - and it might be a reason.
  5. RomanZ
    @loki_racer There is no such param. However, you can run btsync as a special user and restrict it to certain folders using Linux permissions. Just make sure it has full access to its own files.
  6. RomanZ
    @dhfin Is it only icon in the system tray shows that it is paused - or no data is actually synced?
  7. RomanZ
    @arlinsandbulte Can you see synced files if you browse your Nexus device not over the USB cable but with some Android file explorer? I suggest that: 1. Files are actually there, but gallery was not updated that's why music players does not see it 2. Your PC file explorer might have not enough permissions that's why it does not see BTSync files.
  8. RomanZ
    Matthew, Thanks for reporting - we are aware of this issue and area looking for ways to resolve it in upcoming 1.4.
  9. RomanZ
    @studdmufin Are your computers in the same subnet? Are you using VLAN? Are your computers have multiple network interfaces active? While answering questions above, please try setting your computers IPs and ports in predefined hosts list and see if it helps.
  10. RomanZ
    @b0rman There are 2 mechanisms detecting file changes. 1) System notifications. BTSync asks OS to notify changes in sync folders. This one is not 100% reliable in certain cases (some OSes, excessive amount of directories OR excessive depths or dirs, etc.) 2) Folder rescan. Once per period (600 seconds by default) BTSync rescans sync folders for changes just in case if method #1 failed. According to your description the way #1 is not working well and OS does not send notifications by some reason. How many folders / files do you have? What is the structure of folders? Is it flat or extremely deep?
  11. RomanZ
    @dsolvegmbh BTSync consumes around 400 bytes of memory per file(folder). So, 512 Mb RAM should be enough to track all the 120k files. You can try to run top -p <PID_of_BTSYNC>command to see how much memory (in percent of all available system memory) it consumes - and get some feeling if it has enough memory. Also, are you using 1.3.106 build? There was important fix related to the indexing of files.
  12. RomanZ
    @all Thanks for clarification, I've got the main demand of "running sync as service" as "run with no user logged in with ability to control btsync". @shallowz No big news for now. Feature won't be a part of upcoming 1.4, but we still plan to implement it in future.
  13. RomanZ
    @oldschoola There is a special mode of running BTSync - with a config file. To do it, you need to run BTSync with --config command: ./btsync --config <path_and_name_of_config_file>You can get a sample config file if you run ./btsync --dump-sample-config
  14. RomanZ
    @SchmitzKatze, Could you please collect a debug log from 1.3.106 and send it to me to syncapp@bittorrent.com? Please mention this forum topic in the message body, note that log goes for RomanZ, and mark down the time when the "idle" state begins - I'll find out what BTSync consumes 10-12% of CPU for.
  15. RomanZ
    Yes. Please see here. Each topic starter contains change log and the link to previous version change log.
  16. RomanZ
    @normalizer2000 I'll check it in the lab and let you know the results. Thanks for reporting.
  17. RomanZ
    @simondarren, Thanks for the information. My first guess was that files on B were touched / changed while BTSync is off. In this case BTsync will think they are the most fresh once it starts again. However this is not your case. By some reason Sync decided that files on B are newer and took decision to sync them back to A. I would like to find out why. I wonder if you can turn on debug logging on both A and B and set log_size advanced preference to 200? In this case we will have a good chance to capture this event in debug log if it happens again.
  18. RomanZ
    All, Could you please try running official binary manually (not via PPA package) to seeif issue persists? We did not manage to reproduce CPU usage in idle mode in our lab.
  19. RomanZ
    @mrspcs The API is rather simple and is a set of URL requests which are sent to over HTTP to a tiny web-server ran by BTSync binary. There are some wrappers were published on the forum by community, while it is possible to use it even without any wrapper.
  20. RomanZ
    exactly. Please send it to us via syncapp@bittorrent.com. Please refer to this forum topic in your message.
  21. RomanZ
    @zarg Did you had a chance to collect crash report of BTSync so we can analyze it?
  22. RomanZ
    @werham It looks to be an issue, I've managed to reproduce it in the lab. Once pre-created sub-dirs are removed from sync folders, BTSync does not recreate 'em and never sync files there anymore. I'll check when and how it can be fixed.
  23. RomanZ
    @knireis We are aware of this issue and going to fix it in upcoming 1.4 release.
  24. RomanZ
    @Vedmedka There is no any built-in limitation on amount of folder. Your case looks to be an issue / bug. We'll try to reproduce it in our lab and debug.
  25. RomanZ
    @beandolph6 No, the readonly dir attar should not be a culprit. I suggest collecting debug logs from both non-syncing computers and sending to us for analysis to syncapp@bittorrent.com. Please refer this forum topic in the message body.