linenoise

Members
  • Content Count

    19
  • Joined

  • Last visited

About linenoise

  • Rank
    Member

Recent Profile Visitors

323 profile views
  1. Looking remotely, no luck with the new build. Behaviour looks the same to me. Will get you some logs.
  2. Thanks Helen, I'll give this a shot for you ASAP. Awesome to see the quick turn around on this btw.
  3. Got this sorted, or at least worked around via support. Under Options > Preferences > Advanced > Open power user preferences I was advised to set the folder_rescan_interval to 0, turning it off entirely. Behaviour of BitTorrent Sync seems identical in my use case and the CPU usage is the best I've ever seen it. That said, there's a definite increase in usage between 2.2.x and 2.3.x that's apparently being looked at.
  4. I'm still seeing this with 2.3.1 even after a complete resync of all my data in a fresh folder unfortunately, will submit the logs. Not sure if it's related but I noticed that the resync process from scratch was also VERY slow at times with transfers freezing for over 30 minutes at times despite the machines all sitting on the same LAN at the time.
  5. I've got what's admittedly a pretty large share, ~38GB, syncing between several Macs and a NAS. 2.3 has been great on the NAS and it works fine on the Macs except the thing is indexing several times an hour and chewing huge amounts of CPU and battery when it does. CPU will peg a core at 100% for 15 minutes at a time and the Energy Impact on my laptops puts BitTorrent Sync as consuming about twice as much power as everything else running on those machines combined. This was a complete non-issue with previous v2.x versions. Is there anything I can provide to help debug? [Here is a possible solution build - RomanZ]
  6. Thank you very, very much for listening to the concerns of the user base on the Pro licensing model. It's a rare thing these days and deserves a lot of respect. As a minor gripe, are we able to get the NAS/Other Devices clients kept more closely in check with the desktop and mobile releases? Are these builds you guys do or are they handled by other groups?
  7. This is definitely an issue, and broader than just the NAS based clients. Start-up indexing of large folders is miles quicker to complete on OS X with the client paused.
  8. @GreatMarko, all updated. Mostly Macs and a Synology NAS. Interestingly, I think I've found the culprit. Does BTSync have some code that determines how much upload bandwidth is available and throttle and/or delay entirely transmission? If so, it looks like it might be overzealous. I've got some very large transfers occurring from the parent network at present via sftp. The upload those transfers are using seems to be entirely blocking BTSync from working despite intentionally having been throttled to leave headroom for other services though to be fair we do have rather constrained upload bandwidth where I am, capping out at around 2.5Mbit/s. Stop the sftp uploads, and restart the remote client and everything synchronises properly. Start the uploads again and BTSync grinds to a halt entirely after a while for remote clients and particularly seems to have problems with remote clients starting. A client started remotely whilst the parent network is stalled out doesn't seem to ever get going without a manual restart, even if you halt the sftp uploads, though it does transfer a bunch of data. I've not seen this in the past with .120 and I would have been doing similar uploads, its part of my work, but it makes me wonder whether this could be triggering an issue that runs beyond just this point release. I'm probably pushing the client a bit harder than most as well, the share in question is ~40GB and ~210,000 files.
  9. Ironically this seems to have introduced a syncing issue after I was having a pretty good time with .120 Peers, usually (always?) ones on isolated networks, start up, complete their indexation and then report large numbers of files to upload to every other peer in the swarm. Other peers show themselves as synced but sometimes have a small number of files needing to be sent to the stuck peer. Not sure yet whether this is symptom or side-effect, suspect the latter. Result is the stuck peer fails to sync anything at all, up or down.
  10. Bittorrent Sync uses a modified Bittorrent protocol, possibly so much so as to be incompatible. It would be interesting to add support however. A more interesting feature for Bittorrent Sync to be able to generate a single torrent for a single file you wanted to share with someone and have your peers automatically act to seed that torrent.
  11. Maybe sheer coincidence but updated my desktop clients to 2.0.85 from 2.0.82 yesterday and have had no issues with the NAS since.
  12. 2.0.81 (from memory only) was working flawlessly on my Synology Cedarview devices. 2.0.85-1 works for a while and then crashes as a service. Restarting the service restores service for a while but crashing has been consistent.
  13. There really needs to be a "BTSync Home" product that's a single, fairly cheap one off cost. This doesn't impact me much at all, I only sync a single large tree and I've a compelling use case for the Pro features so will be subscribing anyway once the NAS clients get updated. But I can definitely see this being seen as a big degradation for a lot of home users who may never need some of the fancier Pro features. It's also definitely going back on the statements originally made about how 2.0 was handled which is pretty disappointing to see.
  14. Fair enough. I'll leave the more important stuff where it is then and start a parallel folder.
  15. Hi there, Maybe missing something or maybe this just isn't in yet. I've been syncing a 30GB folder with 1.4 for some months. I've installed 2.0.51 on a few devices and it's found that folder and all seems to be working well. How do I update this folder to a 2.0 sync rather than using the backwards compatibility? Not possible yet?