tuxpoldo

For sure this is not a problem of the packages. Please report it as a BitTorrent Sync issue in the Troubleshooting Forum.

If you have a few minutes of spare time, write them about your disappointment: info@poeditor.com - they are reading the mails and I think it is important to let them know that they are moving in the wrong direction.

Done. Thank you a lot for your help! The new UI of POeditor is really ugly, don't you think? I have told them about my feelings

BTW: I'm updating the server package to support the new advanced settings provided by BitTorrent Sync 1.3 with debconf and obviously there are some new strings to translate. It would be really nice, to get some new contributors in order to speed up this process. Basically I can release immediately, but I would like to wait a few hours to see if someone translates the missing strings. If you like, take a look at the project page! Thank you all!

Done! Thank you very much for your contribution!

Since the resolved is cut exactly at the physical length of the name of the symbolic link, I suppose that you are right. I think that the developers have added the resolving of symbolic links later, but forgot to allocate a new memory location for the result...

Ladies and Gentlemen, and again I'm pleased to announce a new version: btsync-gui (0.8.1-1) unstable; urgency=low * Added transfer status indicator to all tabs of the main window except for the preferences pane (1.3 UI) * Added detailed API timing info to logging * Added default support for new advanced preferences of version 1.3 (Closes #119) * Added Czech translation by Marek Lucas (Closes #111) * Added Russian translation by Sergey Shlyapugin (Closes #112) -- Leo Moll <leo.moll@yeasoft.com> Mon, 01 Apr 2014 19:31:29 +0100

Mhhh... int physlen = sizeof("/home/ziomek/Sync/Laptop");printf ("Physical Length is: %i\n", physlen);// Physical Length is: 25// ...think about the trailing 0 ("\0")// now resolve the link and write it to the same buffer or to a buffer of the same size...char *newstr = pseudo_resolve_link("/home/ziomek/Sync/Laptop")printf ("Real path: %s\n", newstr);// Real path: /home-bulk/ziomek/Sync/Laptopchar szTemp[256];memset (szTemp, 0, sizeof(szTemp));strncpy (szTemp, newstr, physlen);printf ("Et voila: %s\n", szTemp);// Et voila: /home-bulk/ziomek/Sync/Laprintf ("Length: %i\n", strlen(szTemp));// Length: 25// (the same as physlen)Maybe the symbolic link resolver does it in-place (and maybe overwrites also other memory?)...

There is no special way to do it. But you can do the following: pkill -u $(id -u) -f btsync-guibtsync-gui The only problem is, that you have to keep the terminal window open... Or instead of restarting it from the terminal window, you can start it from the application launcher..

The standard i386 version is OK for your system. If your are using Debian or Ubuntu or Linux Min or any distribution derived from Debian, you may take in consideration to use the Desktop GUI Package. This will make your live much easier. If you are using Arch Linux, there is also a very good package - see the same thread.

This seems rather more to be a problem of the btsync executable itself, more than the GUI. In any case it may be related to one of the bugs fixed with 1.3.77. Unfortunately I'm still not able to provide the new package since the internal download location is not available for this release and one binary is missing in order to create the packages.

Hi Roman, sorry, but I think that 100msec is not very fast if previously it took 7 msec. I get these values with only 4 shared folders. Imagine a system with 100 or 1000 folders... The 100msec with 4 folders are visible (it takes a small moment to update) but not really disturbing. I have still not tested it with many folders, but I'm afraid it will make a huge difference. And you would see it, since currently the GUI is not multithreaded. During API calls, the GUI is unresponsive... In any case the question is: what is taking so much longer? The processing of the call, or only the session setup? I'm not totally sure, but it is my suspicion, that the requests library currently sets up a new connection for every call. This is not totally clear for me, since the documentation of the requests-library is somehow confusing on that. But I will make a test with a slightly different implementation.

Duh.... Launchpad has scheduled the builds a lot of time later: amd64: Start in 41 minutesarmhf: Start in 6 hoursi386: Start in 38 minutesThese times are not really reliable. Sometimes it takes twice the time, sometimes, if one or more build in the queue fail, it may start immediately...

Thank you! Want to to see something funny? Look... As soon as the btsync-common package will be available on Launchpad, you should see in realtime (with a sampling rate of 0.00055 Hz :-) the download storm....

After 800 Downloads without any complaint, I will push it also to Launchpad in a few minutes...

After 800 Downloads without any complaint, I will push it also to Launchpad in a few minutes...

Can anybody confirm this? My first impression by testing 1.3.67 with the btsync-gui is that the API is really slower. With 1.2.67 the GUI is really fast and the adaptive query interval was never changed on a local system. The timings of the API calls are now sooooo slooooow that on the local system the adaptive query interval of the btsync-gui is raised to 4000 msec... Any explanation for this? Some more info on timings. This is the normal indicator refresh cycle of btsync-gui with 1.3.67 WARNING:root:Cycle duration was 112 msec - Adaptive timeout changed to 4000 msec to avoid API floodingWARNING:root:Cycle duration was 85 msec - Adaptive timeout changed to 2000 msec to avoid API floodingWARNING:root:Cycle duration was 113 msec - Adaptive timeout changed to 4000 msec to avoid API floodingWARNING:root:Cycle duration was 84 msec - Adaptive timeout changed to 2000 msec to avoid API floodingWARNING:root:Cycle duration was 112 msec - Adaptive timeout changed to 4000 msec to avoid API floodingWARNING:root:Cycle duration was 83 msec - Adaptive timeout changed to 2000 msec to avoid API floodingWith 1.2.92 I had to add an additional log message in order to display the timing, since this never happened: WARNING:root:Cycle duration was 7 msecWARNING:root:Cycle duration was 6 msecWARNING:root:Cycle duration was 5 msecWARNING:root:Cycle duration was 7 msecWARNING:root:Cycle duration was 7 msecWARNING:root:Cycle duration was 8 msecWARNING:root:Cycle duration was 7 msecAs you can see, the API is more than 10 times faster! This is basically the code that is executed: def btsync_refresh_status(self): if self.connection is not BtSyncStatus.CONNECTED: logging.info('Interrupting refresh sequence...') return False logging.info('Refresh status...') indexing = False transferring = False try: folders = self.agent.get_folders() for fIndex, fValue in enumerate(folders): if fValue['indexing'] > 0: indexing = True# this takes too much resources...# peers = self.agent.get_folder_peers(fValue['secret'])# for pIndex, pValue in enumerate(peers):# if long(pValue['upload']) + long(pValue['download']) > 0:# transferring = True##### speed = self.agent.get_speed() if transferring or speed['upload'] > 0 or speed['download'] > 0: # there are active transfers... self.set_status(BtSyncStatus.CONNECTED,True) self.menustatus.set_label(_('{0:.1f} kB/s up, {1:.1f} kB/s down').format(speed['upload'] / 1000, speed['download'] / 1000)) elif indexing: self.set_status(BtSyncStatus.CONNECTED) self.menustatus.set_label(_('Indexing...')) else: self.set_status(BtSyncStatus.CONNECTED) self.menustatus.set_label(_('Idle')) return TrueThe API calls are one self.agent.get_folders(), one self.agent.get_speed() and one self.agent.get_folder_peers(fValue['secret']) for every folder. The system has only 4 folders.

Fine for you. But this is not a solution for the problem. The shared folder is shared between a lot of Macs and it is really GREAT that now all the extended attributes are really shared. But there are also some Linux servers in the share group in order to keep external backups of the data, and therefore it is really ugly, that the system is not able to handle such a situation. Excluding the extended attributes is definitively not an acceptable solution.

Ladies and Gentlemen, after the release of 1.3.67 I made some tests and discovered that basically the release seems to work both with the server as the desktop GUI and user package. Nevertheless I noticed some different behaviour (much slower API access) and I'm a little bit afraid in publishing the new release without any tests made by more persons. Because of this, I will release the binary package for 1.3.67 today only on the YeaSoft repository and not on the Launchpad PPA (this will affect only about 30% of the users). If there will be no really serious problems reported until tomorrow, I will publish the package tomorrow also on the Launchpad PPA. btsync-common (1.3.67-1) unstable; urgency=low * New upstream release -- Leo Moll <leo.moll@yeasoft.com> Wed, 25 Mar 2014 15:25:12 +0100Have fun and let's hope everything works as expected....

Ladies and Gentlemen, after the release of 1.3.67 I made some tests and discovered that basically the release seems to work both with the server as the desktop GUI and user package. Nevertheless I noticed some different behaviour (much slower API access) and I'm a little bit afraid in publishing the new release without any tests made by more persons. Because of this, I will release the binary package for 1.3.67 today only on the YeaSoft repository and not on the Launchpad PPA (this will affect only about 30% of the users). If there will be no really serious problems reported until tomorrow, I will publish the package tomorrow also on the Launchpad PPA. btsync-common (1.3.67-1) unstable; urgency=low * New upstream release -- Leo Moll <leo.moll@yeasoft.com> Wed, 25 Mar 2014 15:25:12 +0100Have fun and let's hope everything works as expected....

Ladies and Gentlemen, after the release of 1.3.67 I made some tests and discovered that basically the release seems to work both with the server as the desktop GUI and user package. Nevertheless I noticed some different behaviour (much slower API access) and I'm a little bit afraid in publishing the new release without any tests made by more persons. Because of this, I will release the binary package for 1.3.67 today only on the YeaSoft repository and not on the Launchpad PPA (this will affect only about 30% of the users). If there will be no really serious problems reported until tomorrow, I will publish the package tomorrow also on the Launchpad PPA. btsync-common (1.3.67-1) unstable; urgency=low * New upstream release -- Leo Moll <leo.moll@yeasoft.com> Wed, 25 Mar 2014 15:25:12 +0100Have fun and let's hope everything works as expected....

Confirmed! All my shares common between Mac boxes and Linux Boxes are stuck on some files (mainly files like "Icon").

I use the requests library with python and never experienced such problems. If you want to look at the code: https://github.com/tuxpoldo/btsync-deb/blob/master/btsync-gui/btsyncapi.py

OK - You are not using the packages from my repository. This guy eugenesan forked many months ago a very very old version of my packages but then he never kept them up to date. But you can fix it: Look into the directory /etc/apt/sources.list.d - there you will find some files. Look into the files. and search for a file containing the follwowing lines: deb http://ppa.launchpad.net/eugenesan/ppa/ubuntu saucy maindeb-src http://ppa.launchpad.net/eugenesan/ppa/ubuntu saucy main Delete this file. Then you have to resync the package list and also to delete the installed btsync package. After that you can reinstall it: sudo apt-get updatesudo apt-get remove btsyncsudo apt-get install btsync

I would say, that you connect to a web ui of a btsync that is definitively not the one installed from the repository. Please enter the following commands and post the output here. Let's see if we find a solution... dpkg -l | grep btsyncps ax | grep btsyncp.s.: as everybody can see, the repository hosts the latest officially released version: http://debian.yeasoft.net/btsync/pool/main/b/btsync-common/