RomanZ

Administrators
  • Posts

    3,588
  • Joined

  • Last visited

Everything posted by RomanZ

  1. RomanZ

    BTSync LogCat

    Sorry - missed the filter part in your original message. We are reducing amount of logs now (on all platforms) so next build should be much more lightweight for you. There is a toggle in debug.txt, although it is not accessible easily on Android. We plan to provide UI switch in future.
  2. Dear community, Sync 2.3.3 is now available. You can get it via direct links below, via official download page or via "Check now" button. Build is also available via auto-update. Direct Download Links: Installer for Windows: x86 installer x64 installer Package for OS X: OS X package Gzip archive for Linux: arm armhf i386 x64 glibc23_i386 glibc23_x64 Gzip archive for FreeBSD: i386 x64 A list of what's new, improved, changed, and fixed in this version is available in the change log. Latest Android build is now also available via direct link: 2.3.4 APK Latest Raspberry Pi package is available via direct link: 2.3.3 DEB Known issues and peculiarities: - Linux users please note: starting from 2.3.0, Sync now creates and uses storage folder (.sync folder) in current directory, not next to binary
  3. RomanZ

    BTSync LogCat

    The only other way I can advise is to filter out the logcat output. Without access to Sync's data you can't prevent it from writing logs
  4. RomanZ

    BTSync LogCat

    nat, As you are connected to the Android via ADT, you are likely have access to the whole FS of Android. Find the file debug.txt in Sync installation and put single "0" (zero) symbol there. Restart Sync. See if it helps.
  5. @gabled-bravado-dell The issue is in the config file, /etc/btsync/config.json. All you need to do is to edit it as @iswrong advised in his post. Alternatively, you can just remove the outdated DEB package that you get in PiWD article and install a new one we've published recently.
  6. Hi, The first step would be finding out if your Sync is crashing or is gracefully shut down. It's rather easy to check. Once you noticed it is down - check the "/usr/local/bittorrentsync/var/sync.log" - it should end with something like: [2016-02-19 12:09:04] SyncFolderScanner: shut down [2016-02-19 12:09:04] Shutdown. Saving config sync.dat This indicates a graceful shutdown. If it is different for you - it is likely Sync crashed and we'll be happy to see the core dump(s). Core dumps by default may be found in: /usr/local/bittorrentsync/var/ /usr/local/bittorrentsync/bin/ /volume1/
  7. @HeinerDD It's weird. Could you please check the content of a file "/proc/sys/kernel/core_pattern" It should contain a path and a mask for core dump files created. Any core dumps where it points to? Also, what about running Sync with ulimit set to unlimited? Last time you responded it behaves like it started a fresh instance of Sync without any old folders. Is it still true? Did you run it with completely same command line as you did before?
  8. @Connor0308 Couple of things to check: 1) Its recommended to move Sync files and folders to a new location. In this case Sync will be able to follow to a new location 2) Permissions and ownership. Should now belong to btsync user. 3) You can check the /var/lib/btsync/sync.log for more details after start (well, attempt to start) the service.
  9. @kornac Try do the following: when you SSH to Syno, navigate to "/var/packages/bittorrentsync/scripts" and run "sudo ./start-stop-status start" and let me know the output of you see (ensure that no other versions of Sync are running prior you do it, of course). This is pretty much the same Syno does when you click the "Run" on DSM.
  10. @kamborio 1) 2)It looks like there is some misunderstanding. There is no hard coded limitations or artificial capping. Sync's WebUI is pretty much standard HTTP server. By default it listens a loopback only for security purpose, but can be configured to listen all NICs (or some particular NIC). As a standard web server it can be accessed from outside of your LAN, and as admin of your net you'll need to take care of connectivity to WebUI port. Does it makes sense now or you expect something different? 3) Upon installing 2.3.x Sync prompts if you want to run it as service. If you agree, it will ask you the username which you want to run Sync under. If later your want to change it - you can do it in services.msc, though you'll need to take care to transfer Sync's service data (and take care of permissions, if necessary), otherwise you'll get an empty instance.
  11. @gabled-bravado-dell These 3 types of folders - standard, advanced and encrypted are all different in core and are designed for different usages. Main advantage of advanced folder is ability to grant and revoke access - which is useful when collaborating. Encrypted folder are more for personal usage - you are sharing your own data to yourself and to some 3rd party which you definitely do not trust. There is no point in revoking access from yourself or from 3rd party which (when got the proper key) does not has any access anyway. From CPU load POV advanced folders are rather heavy, as well as encrypted folders are. Adding encryption to advanced folders going to make it really slow and consuming for desktop computers and unbearable for mobile devices.
  12. @kornac You are welcome! Although I'm surprised that it does not works when started by the DSM itself. The DSM starts it with a next command line: /usr/local/bittorrentsync/bin/btsync --config /usr/local/bittorrentsync/var/sync.conf I suggest to stop your current sync (just killall btsync, don't do kill -9, it's too painful for Sync) and run the command above. See if it a) starts the process and if Sync is going to listen port 8890 (which is default for Syno and is actually mentioned in config file).
  13. @kamborio The main thingie here is to put the sync.conf file to the "%appdata%\BitTorrent Sync Service" of the user which runs service, as %appdata% is different for every user in OS. The "listen only loopback" behavior is default behavior for any WebUI installation of Sync - as you mentioned, by security reasons. So the default behavior just slipped into "Run as Service" feature. Indeed, it is not convenient and the checkbox sounds much more straightforward solution. We'll put it in future plans - meanwhile, you can use the conf file workaround.
  14. @Connor0308 No such flag. So, if any of your peers will know that there is another external peer they can contact - they'll attempt to contact it. So enabling prededined host on your VPS and disabling other means of discovery is necessary step to isolate it from spontaneous connections from your other peers.
  15. @alexisargyris Check now and auto-update will never ever replace the debugging build with 1000x build number. Your Sync believes that your build is newer as the number is greater, so it is designed behavior. As @Moe recommends - just download it and install manually. And thanks for the good news - we were working hard to get the CPU issue addressed.
  16. @kornac Lets try to start it manually (like on screenshot here but with one extra parameter: ./btsync --webui.listen 0.0.0.0:8888 Try to connect to IP:8888 after that and let me know if it helped. If it did not helped - I suggest checking if btsync process is running and listening for port 8888.
  17. Connor, By default, speed limit is only applied to external IPs and not applied in local network. Also, you can try to force your VPS only to connect NAS. To do it, disable tracker on VPN and put your NAS IP (well, your NAT public IP - you'll need to port-forward) and listening port. As a result, VPS will only talk to NAS as it can't discover other devices via tracker server.
  18. Dear community, Sync 2.3.2 is now available. You can get it via direct links below, via official download page or via "Check now" button. Auto-update is not available yet. Direct Download Links: Installer for Windows: x86 installer x64 installer Package for OS X: OS X package Gzip archive for Linux: arm armhf i386 x64 glibc23_i386 glibc23_x64 Gzip archive for FreeBSD: i386 x64 A list of what's new, improved, changed, and fixed in this version is available in the change log. Latest Android build is now also available via direct link: 2.3.3 APK Latest Raspberry Pi package is available via direct link: 2.3.2 DEB Known issues and peculiarities: - Linux users please note: starting from 2.3.0, Sync now creates and uses storage folder (.sync folder) in current directory, not next to binary
  19. @PaulU It's more "Linux way" to install it from repo and it is also more convenient to control Sync in that way as well as keep it up-to-date. The main drawback is that now package is no longer supported (although, our community member @Silvenga provided a fork for this package IIRC, see this topic for details). Extracting and startup of Sync is very simple, although less convenient as you'll have to take care of automatic startup yourself as well as manually update it.
  20. @mjlewis Will be happy to see the logs. I suspect that this is a known issue that we've just fixed, although its better to confirm it with logs. Could you please send me some? Note in message body that logs are coming to me and mention this forum topic. Thanks!
  21. @steinbitglis No, it is different crash. We've identified it and working to get fixed.
  22. @sc The 2.3 release had issues, many were addressed in 2.3.1 and even more fixes to come in 2.3.2. Unfortunately, the Support failed to find the root cause of your initial issue with renaming huge folders. The issue is unique and we don't have any other sources of debugging information other than yours setup (it does not reproduce in lab, neither for other users). I apologize for the situation. When we find the root cause and fix it - I'll inform you. @VMoreno Indeed, we get some reports of appearing of .Conflicts folder, although we are still working to get it pinned. If you want to assist - please send us your logs so we can analyze the root cause.
  23. @gl00mer I wonder if Sync stops or crashes. Could you please check if there are any core dumps in 3 locations: /usr/local/bittorrentsync/bin/btsync /usr/local/bittorrentsync/var /volume1/ (should start with @btsync)