RomanZ

Administrators
  • Posts

    3,588
  • Joined

  • Last visited

Everything posted by RomanZ

  1. @magbeat Could you please share a screenshot and exact version you use? Thanks!
  2. @AP-123 We did not release official Synology package yet. Though. SynoCommunity offers their own package, latest version they packaged is 1.4.83. You can try to upgrade it manually - you'll need an SSH access to your NAS and replace old binary with a new one. Binary should stay in "/usr/local/btsync/bin" folder.
  3. @icymatter Then it is not possible to install 1.4 on it. 1.4 is using newer WinPhone API for some new features which is not available on WinPhone8. You'll have to stick with 1.3 for your xperia.
  4. @MerceanCoconut It looks like btsync was not registered during upgrade in HKEY_CLASSES_ROOT. It's rather simple to fix. I'm attaching a reg file - it associates btsync:// with btsync app. Please make sure that path is correct (it may change depending on x86/x64 version of Sync). @icymatter No, this is not the only way. Fixing the registry or reinstalling Sync should fix it. fix_link_open.zip
  5. Kenneth, Sync keeps modification time synchronized, but does not care about creation time or access time. Will mtime work for you?
  6. @PowZone Couple of questions to clarify your issue: 1) Are your running Yosemite Beta or release? 2) When you see high CPU usage - is Sync main window open / minimized? If yes - can you please close it and see if issue still occurs?
  7. @thejae Sorry, no ETA yet. Our NAS group is working hard on delivering official Synology package. @AP-123 Could you please share what exactly is not working so we can assist?
  8. @icymatter 1.4 for WinPhone requires WP8.1 and won't run on WP8. So if it is possible to upgrade your sony xperia OS - you can get Sync 1.4 running on it. The database format of 1.4 and 1.3 is not compatible, therefore downgrade is not possible. If there are any issues we can help you to deal with - please share to syncapp@bittorrent.com
  9. @atte I did a simple test - my Pi indexes 850Mb for around 90 seconds, so it would be 105s/Gb. So, your 350 Gb of data should be indexed for nearly 10 hours. Though, there is one more peculiarity. Sync consumes 1kb of memory per file / folder. So if you've got tons of tiny files, they might not fit into memory as Pi will sink in a swap. What amount of files you try to index?
  10. Working on the fix at the moment! Will release fixed build as soon as fix is ready and tested.
  11. @multra In my tests it is still lower than explorer speed, but it shouldn't be only 10% of your bandwidth.
  12. @artexx Starting from around ~1.4.81 WebUI for Sync by default only listens to loopback interface. For Linux there is a command line option "--webui.listen <IP:port>", though it is not implemented for Windows computers. You can run Sync with config file and specify "0.0.0.0" for webui interface to force it to listen all available PC NICs.
  13. @mversion As @mbob told, it is a known issue. Good news are that we are know the issue and are testing the fix now. Bad news are the fact that fix is not there yet
  14. @ms2oo8 Can I please take a peek at your debugging sync.log? As @GreatMarko said, it should not index that long second time (unless lots of files has changed).
  15. @multra if your switch supports 1Gb connections - it can be faster. The easiest thing I can advise - try disabling the advanced preference "hdd_low_priority" to make Sync more aggressive towards HDD usage. It should be done on both NAS and your Win7 (for NAS you'll need to start Sync in config more to set the setting). If it does not help - I'll be happy to see the speed profiler data and identify your bottleneck.
  16. Sync works with UTF8. There is an issue in Linux filename validator which caused Linux client inability to sync non-ASCII chars. It is fixed for now, so it should be available in next update. ETA for build is still vague - see my previous post.
  17. @Scott1x Please check your .sync\Archive folder for the deleted (or older version) files. We are aware of 2 cases when older file might overwrite newer one. One is when time modification is set to future by app that saved the file (so please check what is the mtime of a file) and second one relates to fact that one of Sync instances was turned off while file file was changing on both computers (which seems to be not your case as Sync was permanently turned on on both peers). To understand what happened we'll need debug logs. It should be collected on both your office machine and laptop, cover the same timespan - which includes the fact of overwrite.
  18. @matthewpapa I've got your debugs, though it is not fully clear why your embedded control shows the page. Please expect answer in ticketing system - we'll respond after deeper investigation of your debug data.
  19. @Merk7 The mechanism of identifying which file is older or newer did not changed in the core. The only related change is that the file being processed immediately after it changed (which actually reduces the chances of "old files" being replaced by "newer files". The discarded newer files can be found in .sync\Archive folder - you can restore them. Could you please share a bit more about the scenario - when you was upgrading, wasn't folders on A and B in sync? How big was the difference? What are the files and if are they saved by editing app (which one?) directly to the Sync folder? Was Sync running when app modified files? Thanks.
  20. @eltopo Right. Updating on Linux should work fine in 1.4. @dariomor The issue pops up only with non-ASCII chars when syncing such files from Linux and Linux-based computers. We plan to fix it next week, though I'm still can't guarantee the ETA.
  21. @Kryptonit3 It is not something new, though unusual for Linux-based boxes. I do not know what stands behind WD's decision to migrate to 64k page - this question is better to be addressed by WD representatives. It requires some effort to set up a new build process with new toolchain on our build server. We would like to do it in future, but It is not planned yet.
  22. @mzweck We are aware of this new feature and would like to use it in future releases.
  23. @Knox Sync shows the error when it cannot find appropriate folder for ID it found (or not found) in Sync folder. Could you please: 1) send an output of "ls -al" command from your "/Users/<your_user_name>/Library/Application\ Support/BitTorrent\ Sync/" dir 2) send at least one .sync\ID file for the folder with such error 3) send sync.log (after properly enabling debug logging) Use syncapp@bittorrent.com address, note this topic and my name in subj, Thanks!