sebknzl

Members
  • Posts

    7
  • Joined

  • Last visited

Everything posted by sebknzl

  1. Hello! I've read the announcment and since we're commercially using BTSync, the expression "free for non-commercial use" caught my attention. This implies that commercial use will have to be paid for. This isn't good news. Can you please shed some light on this and give information on pricing? Thanks
  2. @RomanZ Thanks for the reply! It would be great if you added that... as I said, without such a call it's impossible to provide a user-friendly way of adding folders with the current UI! Cheers, Seb.
  3. Hello! How can I get the https://link.getsync.com/... -link of a folder through the API? This is really needed because in the current version (1.4.93) on OS X, adding a folder with only the key is very inconvenient: Add folder, then: Preferences, View key, Update key, ... That's too much for my users. It would also be nice to have the option to directly receive a btsync:// link in case someone doesn't want the request to go through your servers. Cheers, Seb.
  4. Hi RomanZ! I've sent you a PM with logs and a description. Trying again on a new Windows-account and fresh instances on Linux, I have spotted a difference. It works with a Linux where the ifconfig-output looks normal (i.e. lo and eth0) but it doesn't work with an unusual configuration. If it doesn't work, it attempts to synchronize, transfers at 0.2k/s for about 10 seconds and then stops. On the Windows-side, it logs [2014-01-31 13:12:22.435] Torrent \\?\C:\Users\xxx\Desktop\test\Wildlife.wmv status:137 error:<NULL> meta:1 conns:1 io:0 The "unusual configuration" is an OpenVZ-instance and ifconfig reports something like lo venet0 venet0:0 where only venet0:0 has the actual public IP, both others are 127/8-addresses. I have actually posted an LD_PRELOAD-hack before (see post of mine) but of course I didn't use that now for this test-case. Hope that helps. Regards
  5. Hi! I'm also having this issue, but only from my Windows-PC. In this scenario, I have a Linux-Server running in the Internet, a Mac and a Windows-PC, the latter two in different networks. The Mac-instance can't punch holes via UPnP. The share has 50 GB and around 8000 files. Now, the Windows-PC won't sync with the Linux-instance, always just showing how much it has to upload. BUT it syncs with the Mac-instance. The Mac-instance syncs with both Linux and Windows. I thought it's some problem with my setup, but I've tried: different client-versionscleaning AppData and reinstalling the client to no availadding another Linux-instance on a different machine & IPlooking at the debug-log on both sidesall to no avail. I've given up for now and I'm hoping a future version will fix this. I'm just wondering: Are the devs aware of this problem or is it just me? Regards
  6. Hi! Localized strings are returned with wrong escaping in JSON, e.g.: { "message": "Der ausgew\u00c3\u00a4hlte Ordner wurde bereits zu BitTorrent Sync hinzugef\u00c3\u00bcgt.", "result": 200 } These are escaped UTF-8 bytes, which is wrong. Either don't escape at all, as UTF-8 is default for JSON anyways and if you must escape then see 2.5 in RFC 4627. You should also send a charset=utf-8 along with Content-Type. Regards
  7. Hello! Currently we can't "bind" the IP btsync listens to or rather advertises. In my experience, if a btsync-instance advertises a wrong IP, the instance may not be found quickly by other peers. This is especially annoying if it is supposed to be a "server"-instance. In my case, I have a vserver-instance and btsync thinks its IP is "127.0.0.2". DHT helps, but it's turned off by default. Please Devs, fix that! (Haven't looked, but I'm sure it's already on the Wishlist) I've hacked a workaround for Linux for now, see https://gist.github.com/sebknzl/8027609 -Seb