RomanZ

Administrators
 View Profile  See their activity

  • Posts

    3,588

  • Joined

  • Last visited

 Content Type 

Everything posted by RomanZ

  1. RomanZ
    Enrico, Thanks for the log. From the very first glance I see that some of files get transferred. While we are doing more comprehensive analysis - can you please elaborate your experience? Does it sync something or completely nothing? Does it get stuck on particular files? Thanks!
  2. RomanZ
    @netrex It is a limitation of WinPhone OS. It does not let app to browse and open other's app files, so only way is to open it one by one for now.
  3. RomanZ
    @wiwiec, Does it happens when actual sync is going or even when no sync occurs? It would be normal when sync is transferring data: it has to hash all the data it gets (while hashing is rather heavy operation for low-power CPU).
  4. RomanZ
    Please see 1.3.105 build here. Change log: - WebUI redesigned - Fixed issues causing app crash Previous build change log.
  5. RomanZ
    @honza.m Thanks for reporting the issue. I've managed to reproduce it in lab - it looks like a bug (the images in camera roll are valid JPEG images which should be backed up by Sync). We'll analyze what is the root cause and fix it if possible in the next major release.
  6. RomanZ
    @Benguin Indeed, we are aware of the issue. It happens due to Sync logic on handling of files while Sync is off: when Sync comes up and sees that some file has changed (or simply touched), it is will decide to send it to all other peers immediately and treats it as the most up-to-date file. As a results, in some cases file can get back to life if it was deleted on other peer: when Sync which was down starts - it will send the changed files to all other peers, overriding delete event. It is done by 2 reasons: 1) If user copies some older file which it believes to be more important than one was here before 2) Some of the applications (like earlier versions of Picasa) reset file's Modificaiton Time to zero, leaving no chance to survive for photos it edited. Though, we are working to find more user-friendly solution for this issue.
  7. RomanZ
    @xxERICxx It might happen that BTSync asked you a confirmation to close the app and prevented rebooting? If yes, it's a but - which can be easily workarounded, though: just try to close an app once (click it in the system tray, choose "Quick btsync" and check the checkbox "never show it again".
  8. RomanZ
    @soon_dk What about actual transfer speed when transfer starts - does it saturate the whole channel or some of bandwidth left unused?
  9. RomanZ
    @berserk6996 Please make sure that user running btsync has an ability to write to your storage folder (usually .sync subfolder in the same dir where binary stays) - and in particular, to the "settings.dat" file. If permissions are fine - I would appreciate having JavaScript console log as well as Sync debug log.
  10. RomanZ
    @soon_dk, Thanks a lot for the detailed description. Briefly: glibc 2.3 is unable to receive file/folder change notifications, so only full folder rescan "notices" your sync folder changes - and it occurs once per 10 minutes. In details: your Desktop and Laptop are using "Glibc 2.3" version of Sync. One of the major differences between glibc 2.3 and 2.4 was the ability of 2.4 to set file system notifications, so the very OS is going to notify subscribers that something has changed in the specified folders. Sync uses 2 mechanisms to spot changes: file system notifications (if available) and full folder rescan (occurring every 10 minutes by default). In your case only 2nd mechanism is working. I'd advise to upgrade your glibc to 2.4 or newer - and get the version of Sync working with glibc 2.4.
  11. RomanZ
    @acgamst Sync uses different mechanisms for discovery of peers in LAN and over WAN. I suggest that your peer are connected over internet. In this case every peer completes 2 steps to discover others: 1. Get the file "http://config.usyncapp.com/sync.conf", find out what is the IP of a tracker in the file 2. Contact tracker (TCP or UDP over port 3000) to find out where are other peers located I suggest that your migrating laptops fail with step 2 (it is very unlikely they can't get the file over http). Please make sure that the port 3000 is allowed in the locations where you connect laptops. As for the predefined hosts - yes, it is going to work as well. In this case peers will try to connect directly even if tracker server is not accessible.
  12. RomanZ
    @lupa18 Thanks for bringing it to our attention. We are planning some changes in WebUI, so this issue is very likely to be fixed.
  13. RomanZ
    @Garet Indeed, the most CPU-consuming procedures done by Sync are hashing and encryption (encryption is a bit lesser if CPU has HW AES support). It is done mainly during indexing of changed files - and during file receive operation. There is no any build-in means to limit CPU and mem usage. However, it looks like you are using Linux-based machine, so I can advise using cgroups feature to limit CPU load for Sync.
  14. RomanZ
    @soon_dk Do I understand correctly that after connecting back RPI device it does not get the file? What about desktop - does it download file from laptop?
  15. RomanZ
    @cjbr54 The screenshot says that Sync lacks of permissions to write to the selected folder. I suggest connecting to your NAS over SSH and checking: 1) which user is running btsync process 2) if this user has enough permissions to write to the A1 folder. Also, I see that the link for sinology indicates that you use 1.2.82 version of BTSync while 1.3.94 is already available. I suggest you update the binary on the NAS.
  16. RomanZ
    @stanha, I'm joining GreatMarko, and adding: the issues raised and bugs reported are not ignored. All of them are categorized and brought to development attention. They are fixed - or planned to be fixed according to their severity and impact.
  17. RomanZ
    @stanha I need debug logs from the peer that is hanging - and, yes, debug logging starts only when you restart the BTSync on peer. Other logs might not be useful.
  18. RomanZ
    Okay, please share the results once you get it.
  19. RomanZ
    @DavceT No, not actually. in general, Sync supports 2 kinds of secrets: Read-only (RO) and full access (RW). When you are doing a backup, the device owns RW secret and all backup devices (your computers) own RO secrets. RO secret prohibits propagation of any changes. So if you change anything on peers owning RO secret - it has only 2 choices - discard your changes and re-get files from RW peers, or no longer update files which you've changed. The second behavior is default.
  20. RomanZ
    @bherila No need in logs, thank you. The issue was successfully reproduced in our lab and will be fixed eventually.
  21. RomanZ
    @stanha No dump needed. First of all I need debug logs from your peers - lets see what is happening inside. Please send them to syncapp@bittorrent.com, also mention this topic in message body.
  22. RomanZ
    Thanks for info!
  23. RomanZ
    @soon_dk No, the speed should be higher. Could you please try to disconnect RPI (or kill btsync running on RPI), restart other peers and see if they will saturate your bandwidth?
  24. RomanZ
    Drop to syncapp@bittorrent.com. Note this topic in message body.
  25. RomanZ
    @ei96naNi Its simple to check if log turned to full output. On desktops with UI you need to right-click the Sync icon in system tray, see if "Enable debug logging" menu item is ticked. On Linux-based systems check if file "debug.txt" exists in .sync subfolder near binary file (see details here).