kos13

Employees
 View Profile  See their activity

  • Posts

    750

  • Joined

  • Last visited

  • Days Won

    92

 Content Type 

Everything posted by kos13

  1. kos13
    What version of Sync you are using?
  2. kos13
    Could you please send us logs? Steps could be found here
  3. kos13
    We don't have native Android build. The build that is on Google Play is just a wrapper for Linux version that was made by someone.
  4. kos13
    We need logs for this case to track down the issue. If this is reproducible please send us logs. Steps are
  5. kos13
    We need logs for this case to track down the issue. If this is reproducible please send us logs. Steps are
  6. kos13
    Can you send us logs? seems like a problem and we can't reproduce it so far. You could find steps to collect and submit logs here - http://forum.bittorrent.com/forum/56-bittorrent-sync/
  7. kos13
    1.0.116 is old version please upgrade to 1.0.134. We have a lot of crashes fixed.
  8. kos13
    We check for new builds daily, so you should see new build in Linux Web UI today.
  9. kos13
    no
  10. kos13
    Even the file is deleted, Sync keeps record about this event. This record is needed for the following scenario: new peer connected and has the deleted file, Sync will need to decide whether it should be deleted on peer or this is new file that needs to be downloaded. Therefore memory doesn't go down after deletion of the file. I described how it works now, but we are going to change that.
  11. kos13
    Could you please turn on logs and send them to us? Detailed steps are here
  12. kos13
    This is just a log record. This is nothing wrong with the Sync. Some leftover from BitTorrent p2p client
  13. kos13
    If I read the script correctly it creates 1M files. Sync can consume 2Gb for 1M files, but not for 300 files.
  14. kos13
    This is not normal. Can you give us additional info? You used sleep on computer? OS version? Bt sync version?
  15. kos13
    Can you follow steps from here We will need logs to identify the problem.
  16. kos13
    Can you please give us more details? Sync can't allocate that amount of memory for 300 files.
  17. kos13
    What Sync build you are using? We had some fixes around this, so if you use latest one 1.0.134 then it might be some new issue.
  18. kos13
    Sync at the moment has linear memory grow that depends on amount of files. This will be changed in next builds.
  19. kos13
    We do need logs to detect the issue. This topic describes steps In your case we will need logs from the Debian server(arm) that crashed. If possible could you also send us dumps?
  20. kos13
    I would like to keep you updated on our progress. 1. Sync mobile for Android and iOS. We have both versions running, native code. There are a lot of mobile specific things that needs to be done. This takes time, so please be patient. But there will be something that will surprise you. ETA? Don't have any specific date. 2. Memory and CPU optimization. This is very important for us, and you should expect significant drop in memory and CPU usage for the next version. Not sure if we will be able to do everything we want, but our goal to make Sync most effective app. 3. One major feature. I am not ready to share details, but it will be something you have asked for. 4. Bug fixes. Thank you for your support and help. kos
  21. kos13
    Can you look to the file in .SyncTrash and give us idea what is there?
  22. kos13
    No, this is not our application. It is just Linux build wrapped for Google Play store.
  23. kos13
    Sync is base on file timestamp. So if it not changed, Sync will not check the content of the file. This is correct. Sync will transfered only changed chunks.
  24. kos13
    Thank you! URL fixed.
  25. kos13
    Sync uses strong random generators. Mac, Linux: /dev/random Windows: CryptoAPI