tuxpoldo
-
Posts
730 -
Joined
-
Last visited
-
Days Won
27
Posts posted by tuxpoldo
-
-
It is ugly + the new "cross platform" version is still unusable on mobile devices.
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.
-
Could you please add me back to project btsync-deb? I was confused of new Poeditor ui and signout from the translation.
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!
-
I can help you with the Bulgarian translation. Please add table for the Bulgarian language!
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?)... -
hey tux,
how can i restart btsync-gui from the terminal?
thanks,
jaithn
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.
-
I'm having an issue with it: after a successful install on Linux Mint 16 running on Intel 64, I can load folders in and I've got the folders to show up on each computer, but the Linux status (in my menu) is always "Idle" and it won't actually transfer anything. Note: transfer seems to work from the mac to the linux, but not the other way around.
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 minutes
- armhf: Start in 6 hours
- i386: Start in 38 minutes
-
you rock
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 flooding
With 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 msec
As 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.
-
That is why I have excluded them in my .SyncIgnore on the Mac, as I am mainly syncing with FreeBSD servers for backups and do not need the xattr
com.apple.FinderInfocom.apple.metadata:_kMDItemUserTagscom.apple.ResourceForkcom.apple.metadata:kMDItemFinderCommentcom.apple.metadata:kMDItemStarRatingcom.apple.metadata:kMDItemOMUserTagTimecom.apple.metadata:kMDItemOMUserTagscom.apple.metadata:kMDItemOMUserTagTime
Since then, all shares are syncing without problems.
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 +0100
Have 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 +0100
Have 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 +0100
Have 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
-
Here is the output:
ladmin@kif:~$ dpkg -l | grep btsyncii btsync 1.2.67-0~eugenesan~raring1 amd64 Private network P2P file synchronisation daemon(s)ladmin@kif:~$ ps ax | grep btsync 1317 ? Sl 109:04 /usr/lib/btsync/btsync-daemon --nodaemon --config /etc/btsync/debconf-default.conf 5274 pts/0 R+ 0:00 grep --color=auto btsync
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 btsync
p.s.: as everybody can see, the repository hosts the latest officially released version: http://debian.yeasoft.net/btsync/pool/main/b/btsync-common/
Debian And Ubuntu Server Unofficial Packages For Bittorrent Sync
in Sync General Discussion
Posted
For sure this is not a problem of the packages. Please report it as a BitTorrent Sync issue in the Troubleshooting Forum.