denormal

New Members
  • Content Count

    5
  • Joined

  • Last visited

Everything posted by denormal

  1. @Helen - thanks for looking into this. I didn't have debug logging enabled so can't shed any further light on the issue. This does not appear to be affecting overall performance (at least that I am aware).
  2. @Helen, I'm using the official Debian packages provided by BitTorrent (as detailed in the BitTorrent blog), with package information given above. The web UI is reporting version 2.3.6 build 378.
  3. I'd like to second the request for the ability to share an Advanced folder as encrypted. One of the best features of Advanced folders is the ability to revoke access for an identity, which can only be achieved with Standard folders by regenerating folder keys. As this affects all peers it can be painful in large teams. In recent BTS clients (at least OSX and Synology), the ability to generate new keys is not present in the UI (there used to be a link to "Update key"). @ArtemPronevskiy - do you know why this removed? I assume the only way to affect this change now is to disconnect a folder and then re-add it (not as elegant a solution).
  4. @GreatMarko - thanks for your quick reply. After posting this I did see that thread - however I'm not sure if this applies. According to the web UI there are no speed limits imposed (attached), and I can't see an upload or download limit in /etc/btsync/config.json or /etc/btsync/user_config.json: { "listening_port" : 0, "storage_path" : "/var/lib/btsync/", "pid_file" : "/var/run/btsync/btsync.pid", "agree_to_EULA": "yes", "webui" : { "listen" : "xxxx" } } Or am I looking in the wrong place? Are there build-time defaults that are being enforced (unlikely)? The assertion failures have come at times when the web UI is reporting transfers at different rates (handful of KB/s through to MB/s). As reported by @agend07 it doesn't appear to be affecting performance.
  5. Possibly related, I am also seeing network-related "assert failed" in the logs running on Debian v8.4 (jessie) on amd64: assert failed /home/jenkins/slave-root/jenkins-Build-Sync-Manually-309/network.cpp:2738 The difference in line numbers may be related to the different build architectures - the assertion may be being triggered by the same conditions as experienced in the original report. Here are the details on the installed package: % apt-cache show btsync Package: btsync Version: 2.3.6-1 Architecture: amd64 Maintainer: BitTorrent, Inc. <support@getsync.com> Installed-Size: 9894 Depends: libc6 (>= 2.4) Homepage: https://www.getsync.com Priority: extra Section: net Filename: pool/non-free/b/btsync/btsync_2.3.6-1_amd64.deb Size: 5191642 SHA256: e730aa9f30fccdda2cea7679d3f506042e246d7c9514591a7c799dcf22cac129 SHA1: 6cc9bcd885151596e575f49cbdcb563ab51d4605 MD5sum: 7d553ca1c7a0757a0531a3140f7232ed Description: BitTorrent Sync is a proprietary peer-to-peer file synchronisation tool. It can sync files between devices on a local network, or between remote devices over the Internet via a modified version of the BitTorrent protocol. Description-md5: 76747236cd3fbbff26384c3d342dbba0 I'm noticing btsync dropping client connections after a short period of file transfer, although this may be related to local configuration and not the result of this assertion failure.