RomanZ

Administrators
 View Profile  See their activity

  • Posts

    3,588

  • Joined

  • Last visited

 Content Type 

Everything posted by RomanZ

  1. RomanZ
    @ocinatas Folder list is stored in %appdata%\BitTorrent Sync\sync.dat file. If you get it empty - it is very likely that someone or some app deleted \ corrupt the file. As for the adding folders again - what makes you think that files were deleted and retransferred? Have you seen it in file manager / explorer? Sync should not delete the files at all if they are same as on other peers (and they are same - as I understood the folder stayed synced before the issue occurred).
  2. RomanZ
    @vocatus Couple of things to try and check: 1. Remove your router port forwards - and let Sync do the job for you - enable UPnP. 2. If you want to control port forwarding on your own - make sure there is no mistake: - You need to port forward the port on router which is marked as "listening port" in preferences on your peer, standing behind your router. - You need to forward both TCP and UDP protocols - You need to make sure that either tracker server is enabled OR you defined your other peer in predefined hosts 3. Check with your provider if it does not put you behind NAT (in this case no port forwarding or UPnP going to help you).
  3. RomanZ
    @pjmsullivan Various apps use different ways to save data (some allocate disk space and write data there, some create empty placeholder and then replace it by renaming temp file) - actually Sync should track all these changes and apply'em accordingly to other peers. The time is saved in unixtime format - there are a bunch of online converters, briefly - it is amount of seconds passed since certain point in the past (Jan 1 of 1970). The app crashes and kills have only immediate effect, i.e. file overwrite happens after Sync (which crashed) starts again. I don't have immediate answer to that. I strongly suspect that DB cleanup (i.e. re-adding folder) will solve the issue for some time. I'd like to get full debug logs from both computers for this issue (if it is reproduced easily) and see if we can find the traces on what really happened there.
  4. RomanZ
    @pjmsullivan Actually your last post makes me to be even more sure that we are facing same issue as with office files. Lightroom starts complaining about inability to open file as it is opened by Sync at the moment. I can supply you an experimental build to see if it will help the issue with Lightroom.
  5. RomanZ
    @b0rman It depends if bad-block is detected by OS or not. If EDC did not detect corrupt data (and the OS API simply returns corrupt file piece) - sync will recalculate hash and propagate corrupt data. If OS detected the error - it will fail the file read API and sync won't have access to the damaged piece of file, so it won't propagate.
  6. RomanZ
    @Bitwise We are getting around 100-110Mbytes/sec in LAN (gigabit ethernet) and nearly 10-11 thru wifi router (802.11n) in our Lab. It looks like there is some bottleneck in your setup. First couple of things I suggest to check: - if your "hdd_low_priority" set to "False" - increase your receive / send buffers 2-3 times (to around 20-30 Mb) - make sure that connection is direct, not via relay server If all above does not help - let's collect profiler data and see what it says.
  7. RomanZ
    @all, I believe the browser window width is enough to fit possible share button? Would you be so kind to share screenshots? Thanks!
  8. RomanZ
    @Bitwise No, it should not queue them up. If you show a new one - the previous is simply discarded. BTW, there is a close button on notification. Does it close if you click it explicitly?
  9. RomanZ
    @jasperwillem Well, the error is pretty self-descriptive. I suggest checking if the user which runs Sync have enough permissions to access Sync folder. Which OS do you use?
  10. RomanZ
    @marcv The speedtests usually do not involve the process of recording data to storage - which is usually a bottleneck for the mobile devices. As for background sync - it is not supported at the moment. Currently the app has to stay displayed to actually transfer data.
  11. RomanZ
    Steve, Please try to set the "folder_restan_interval" and "config_refresh_interval" to some bigger value (both are in seconds) and see if it helps.
  12. RomanZ
    Hi Scott, Can you please collect and send us debug logs from peers affected? Thanks!
  13. RomanZ
    @jtek Sync client is limited to around 200 of simultaneous connections. We cannot clarify it at the moment. It will be more clear closer to release - we'll announce later.
  14. RomanZ
    @fantom Just FYI - Sync does not officially support Blackberry OS, and there are some known issues with Android emulator - so Sync might not be working well on Blackberry.
  15. RomanZ
    @pjmsullivan I did not manage to reproduce the same in my lab. Lightroom did not proved sensitive to changing catalog name or mtime either. It might be the same issue as with the office files. If you try to open it again a bit later - do you receive the same message?
  16. RomanZ
    @Bitwise We are getting around 90% of router's claimed bandwidth in our lab. Other solutions (like, transferring file over CIFS) introduce around 95% of bandwidth.
  17. RomanZ
    @cubik The "error:<NULL>" line in log just indicates the absence of error. I suggest collecting profiler logs and sending to us for analysis - we'll try to see where the bottleneck is. @pjmsullivan There are a number of cases which can introduce "old files overwrite new ones" issue, please check if you are subject of any: - Application crash / unexpected kill (like, kill -9 on Linux). - Shutting down peer with enormous amount of files and forcefully killing the app (same as previous) - Files with mtime from future (will always overwrite files on other peers) - Files updated / moved on 2 or more peers while one peer has Sync off. @b0rman Use the link dropped by @GreatMarko as instructions and drop me a profiler data. We'll try to locate bottlenecks in your setup.
  18. RomanZ
    @wimbit Thanks for testing. Please monitor this topic - we'll prepare a special debugging APK package for you to find out what happens on your Android.
  19. RomanZ
    @iceman600 2 quick ways to workaround it: 1. Replace the "https://" in the link with "btsync://" and try to open in a browser, see if helps. 2. If it does not help - try opening Sync, click the "Cog" button, "Enter key" and paste the link there. Let me know if it helps.
  20. RomanZ
    @Bitwise Yes, it is the the size of buffers for all send and receive operations, app-scale.
  21. RomanZ
    Added the most fresh released (1.4.63 Android) build, same location.
  22. RomanZ
    @cubik First thing to try is to increase send / recv buffers and set "low_disk_priority" to "false". If it does not help - let me know, I'll instruct you to collect profiling data to find out where is the bottleneck.
  23. RomanZ
    @wimbit The trick here is _not_ to backup and restore settings. Could you please do the same but without restoring settings - and see if crashes will still happen? Thanks!
  24. RomanZ
    @Juice370 I guess you got confused with the "Add folder" button. You are "Add-ing folder" on both your NAS and PC, and later trying to update NAS key to read-only, right? You need to follow different scenario. Add folder on your PC, then "Share" it to NAS (or simply copy read-only key). PC will produce the link (or you copy key) which you need deliver to NAS. On NAS click Cog icon, then "Enter key" function and paste your Link or key there, choose the folder. In this case you'll add it with RO permission.
  25. RomanZ
    @BrianR549 Oh, got you - thanks for clarifying. I'll send you experimental build as well if you are willing to try.