Swisstengu

Members
  • Posts

    31
  • Joined

  • Last visited

  • Days Won

    1

Swisstengu's Achievements

Advanced Member

Advanced Member (3/3)

  1. almost same for me - there is already 1-2 requests about this feature for the mobile app. It would require to allow DHT support as well as "known_hosts" in order to be able to completely deactivate the relays and trackers. Hopefully this will be done . It's, on my side, the only missing point… Cheers, C.
  2. It would be really great having some /latest symlink to the latest version, on the synapp server… This way, we may use some wget stuff with md5 checksum in order to auto-update the app when we can't use the "check_update" stuff (like, binary not owned by the running user…).
  3. best way would be Sync having the option in its configuration - I opened a post just this morning with, among other things, this request.
  4. same problem on a nexus4, stock android. 3 folders, about 1.9Mo. Phone's heating, and the battery life has lowered in a very bad way (could last for about 2 days, now about 12 hours…)
  5. same for me at first sight - but then, I tried and Voilà .
  6. Hello, It may be a good thing to allow Sync to start on device boot - I didn't see this option in the configuration, though it may be nice to have it up n'running once the phone/tablet is started. Also, it may be really usefull to have the possibility to add the known_hosts configuration to the shares on the app. In my case, I'm wanting to not use the standard trackers, meaning I'm using DHT… and my phone has some problems finding the source for the sync-ed data… Would it be possible to add such features in a near future? Any roadmap/timeline? Thanks a lot! Cheers, C.
  7. Hello, This was caused by some bug in Sync - have a look at Also, there is the new 1.1.48 which correct this problem. I hit it while sync-ing 1.5To (~200k files). The new version corrects this problem . Cheers, C.
  8. @Dantounet: seems to be an I/O error, according to the error number (it's the sqlite error returned). Maybe the hard drive (or… SD card ? don't tell me you're using btsync on an sd-card…) has some problems. Also, the RPi has an unreliable USB connection - this may create some problems if you have an USB hard drive… For such a use, maybe the cubieboard[1] is better, as it has a dedicated sata port, and it's a bit more robust… Have a look at system logs (such as dmesg), it may give you some more information. Cheers, C. [1] http://cubieboard.org/
  9. Thanks a lot Sergey (I'm the one you had on mail about this problem ). On my side, it's working as expected - nothing bad happened, even with many Sync restarts. I guess it may be good to announce this new version as it corrects what may be called a major bug . Cheers, C.
  10. Hello! About the same problem - I opened a ticket and have some contacts with BitTorrent team. Problem seems to be at sqlite level, some trailing locks or something like that. You can see this by enabling the debug mode, start it over - you'll stumble on SyncDB errors stating it's unable to complete the statement (i.e. cannot insert new content) - the DB is locked. Hopefully this will be corrected shortly. Cheers, C
  11. Sure - but the point is: "Yes, we can!" actually use some custom credentials (provided they are unique - i.e. not used for our private mail account, and so on ). Won't be less secure though provide some nice way to remember the string.
  12. hmm… seems there's really some issue: my sync was stuck this night at ~38-40G (about 10%), sync.log was full of SyncDB errors… I looked in the DB, there are about 3k+ file entries missing in the "files" table - this, for sure, doesn't make 300G, but… Any hint from the Team would be welcome . Cheers, C.
  13. You can enter the secret - there's a (not well shown) field just around the button "scan qrcode".
  14. Yep, true. Was more speaking of SSH for the key exchange .