tuxpoldo

If you have 1.14.2-1 on your system, you have the latest version. You can verify this also by typing: sudo dpkg -l btsync-user Sometimes you can get some communication errors during startup, if the btsync-agent needs more time to startup. The most interesting question is: does it work, or does it not work? This version fixes this problem described by jenhsun Traceback (most recent call last): File "/usr/lib/btsync-user/btsyncindicator.py", line 254, in setup_session self.info[a] = response.json()AttributeError: 'Response' object has no attribute 'json'

In order to verify if a supplied secret is valid, it makes sense to call the "get_secrets" api supplying the secret to test. With certain secrets (e.g.: AYZS32KDN32SF6DWF7IRONKYHQGBHW5OCaaaaaaaa), btsync 1.2.82 on Linux 32 bit crashes without any log message. This behaviour is also reproducible with the Mac OSX version by entering the secret in the folders preferences dialog box. Update: It seems that btsync crashes on this api with every secret longer that 40 chars... Secrets are normally 33 chars long. If you specify a secret with a length between 34 and 40, nothing happened (the chars seems to be ignored). As soon as the length exceeds 40 chars, btsync crashes: leo@debpoldo ~/btsync-deb/btsync-gui $ curl 'http://localhost:9999/api?method=get_secrets&secret=AYZS32KDN32SF6DWF7IRONKYHQGBHW5OCYZS32KDN32SF6DWF7IRONKYHQGBHW5OC'curl: (52) Empty reply from serverleo@debpoldo ~/btsync-deb/btsync-gui $ pgrep btsyncleo@debpoldo ~/btsync-deb/btsync-gui $

And again a new version. Should solve the problems with older Ubuntu/Debian versions. btsync-user (1.14.2-1) unstable; urgency=low * New upstream release 0.14.1 of btsyncindicator - Restored compatibility to old versions of requests library (Closes #btsyncindicator/43) -- Leo Moll <leo.moll@yeasoft.com> Mon, 24 Feb 2014 11:29:04 +0100

Mark found the problem and I think tomorrow we will publish a fix. The problem occurs only on systems with an old requests library (like in Ubuntu 12.04...)

Are there any means to get a one-time secret with the Sync Api?

Hi Folks, does anybody here know how to generate the QR code from the secret? I made some tests with a QR code scanner and it parses the QR Codes from the client as btsync://<secret>?n=<last part of foldername> Is this really correct or is there something more I should know?

OK - the API key you entered is definitively NOT an official API key from BitTorrent Inc. I have no idea what happens, if an invalid API key is supplied. Perhaps btsync goes in a sort of "Punishing mode"? Does anybody here know it? Now I would suggest to invoke sudo dpkg-reconfigure btsyncand remove the API key. BTW: debconf says: "To enable the BitTorrent Sync API, an API key supplied by BitTorrent must be specified into the configuration file. If leaved empty, the API of BitTorrent Sync is disabled (default). API Keys can be requested on the BitTorrent Web Site." Why did you think you could enter something random? Remember: "If you break it, you own both parts"

And again a new version. Thanks to Mark for the new version - every people from non english speaking countries will be happy since the internationalization issues seem to be all solved! btsync-user (1.14.1-1) unstable; urgency=low * New upstream release 0.14 of btsyncindicator - Implemented support for unicode characters in folder and file names (Closes #btsyncindicator/32) - Implemented support for web ui set in non english language (Closes #btsyncindicator/24) - Officially fixed the syntax error in exception handler (Closes #btsyncidicator/39) - Made officially compatible with Ubuntu 13.10 (Closes #btsyncindicator/9) - Modified lockfile checking method -- Leo Moll <leo.moll@yeasoft.com> Sat, 22 Feb 2014 18:23:42 +0100

Perhaps it may be a good idea, if you post also your config files here (obviously without passwords ;-)

This is exactly what is expected to happen. This is exactly what is expected to happen. I suppose you were looking for the log file. The log file is named ~/.btsync/btsync-user.log

Your description of the problem, indicates that the problem is more related to the BitTorrent Sync core itself as to the Debian packaging. Perhaps it is a good idea to post the problem as a separate topic in the forum.

I see you are using the packages fro server usage (btsync). The file /etc/btsync/debconf-default.conf should never be edited manually. You can set all relevant options by executing the following command: sudo dpkg-reconfigure btsync The default instance (the one maintained by debconf) stores the "temporary" files (in fact they are not temporary) in /var/lib/btsync You will find more information about the usage of the server packages in the Server Packages Thread.

Ladies and Gentleman, thank you a lot for the log files you posted here. Unfortunately the information is still not enough, to fully understand the nature of the problems on some systems. Because of this, I prepared a new version with more detailed logging and also some additional code that intercepts a particular situation that should not happen, but happens due to a non fully correct implementation of the context handler in btsyncindicator.py. I would kindly ask you to update to the new version, and send me more log files. In order to avoid the pollution of the forum, it would be nice, if you can send me the log files as private messages. Here the changelog of the new version: btsync-user (1.13.2-1) unstable; urgency=low * Updated man page to reflect recent changes in file and directory structure * Added more logging to the startup script * Updated comment block in btsync-starter to reflect recent changes in file and directory structure * Improved handling of context manager lock file that will not be automatically deleted on indicator stop (what should happen but does not) -- Leo Moll <leo.moll@yeasoft.com> Fri, 21 Feb 2014 11:38:10 +0100 On my debian wheezy test system, I installed the new version, stopped anything, deleted the old log file and than rebooted the system. After reboot and logging in, everything was working fine. Then I logged out, and logged in again and again everything was working fine. Here the log file of such a session: 2014-02-21 12:35:49+01:00 btsync-starter: start2014-02-21 12:35:49+01:00 make_user_files: User specific files and directories created2014-02-21 12:35:49+01:00 start_frontend: begin2014-02-21 12:35:49+01:00 start_frontend: frontend not running but LOCKFILE detected! Strange! btsyncindicator should handle it2014-02-21 12:35:49+01:00 start_frontend: starting frontend with default config file /home/leo/.config/btsync/btsync-auto.conf2014-02-21 12:35:49+01:00 start_frontend: process is running with pid 160502014-02-21 12:35:49+01:00 start_frontend: end2014-02-21 12:35:49+01:00 btsync-starter: no running statefile detected - forking runner...2014-02-21 12:35:49+01:00 agent_runner: begin2014-02-21 12:35:49+01:00 agent_runner: starting up components...2014-02-21 12:35:49+01:00 btsync-starter: end2014-02-21 12:35:49+01:00 make_user_files: User specific files and directories created2014-02-21 12:35:49+01:00 start_frontend: begin2014-02-21 12:35:49+01:00 start_frontend: process is running with pid 160502014-02-21 12:35:49+01:00 start_frontend: end2014-02-21 12:35:49+01:00 start_agent: begin2014-02-21 12:35:49+01:00 start_agent: starting agent with default config file /home/leo/.config/btsync/btsync-auto.conf2014-02-21 12:35:49+01:00 start_agent: end2014-02-21 12:36:46+01:00 btsync-starter: start2014-02-21 12:36:46+01:00 make_user_files: User specific files and directories created2014-02-21 12:36:46+01:00 start_frontend: begin2014-02-21 12:36:46+01:00 start_frontend: frontend not running but LOCKFILE detected! Strange! btsyncindicator should handle it2014-02-21 12:36:46+01:00 start_frontend: starting frontend with default config file /home/leo/.config/btsync/btsync-auto.conf2014-02-21 12:36:46+01:00 start_frontend: process is running with pid 166722014-02-21 12:36:46+01:00 start_frontend: end2014-02-21 12:36:46+01:00 btsync-starter: btsync-agent already running - nothing to doIMPORTANT ADDITIONAL INFORMATION FOR THOSE OF YOU USING UBUNTU RARING: Launchpad has ceased support for Ubuntu Raring (13.04). Because of this I'm not able to publish new versions of the packages for Raring. If you are still using raring and want to keep your system up to date, you should remove the ppa and add the alternative ppa by using the instructions for Debian as described in the initial posting.

Hi folks! some days ago, I announced that I'm working on something new. Although it's too early to announce it, I would like to give you some hint. Take a look here... and here... and here... and here. Maybe with a little bit of luck, the braves may have a chance to test it in 7-8 days....

After executing btsync debug 0000 there will be a file ~/.btsync/debug.txt containing 0000 The startup and runtime script will check for the existence of this file in every call to the logging routine, so there MUST be a debug output file. But you really have to reboot your machine, to get the new startup and runtime script to be executed. Can you please check in this EXACT state, if the process is running or not? You can do this by executing: pgrep -u $(id -u) -f btsyncindicator.pyIf it is running, the PID (a numerical value) will be shown. If not, nothing is shown. This is totally impossible. The script is full of logging statements and every logging statement writes via a single redirection in the log file. Are you sure, that you REopened the log file? The best was to follow the changes is to open a separate console with the command: tail -f ~/.btsync/btsync-user.log I have no explanation for that. I also get sometimes this error message on my systems, but it has absolutely no effect on functionality... But I'm still investigating. The main problem, is that I am absolutely not able to reproduce the described effects on any of my systems... What the hell may be the difference between them?!?! (Communication error 401) => HTTP 401 is "Unauthorized" This is really strange. Do you have set any credentials on your btsync? There is a way to break it: If you have set any credentials, either by putting them directly in the config file or by entering them in the Web UI, there is no way back to remove them. If you removed the credentials from the config file, they are still in effect since btsync stores them in an internal database. The only way to solve the problem, is to set credentiuals in the config file AND LEAVE THEM THERE. The credentials in the config file will alsoway overwrite former credentials set in the internal database and btsyncindicator will then use them in order to connect to the system.

I just released version 1.13.1-1 of btsync-user. This version contains the promised logging for the wrapper script that coordinates the launch and runtime of btsync. I would kindly ask those of you experiencing the problems reported during the startup phase, to activate logging by issuing the command btsync debug 0000 It does not matter, which debug flags you specify (0000 to FFFF) - as soon as logging is activated, the startup script logs everything. The logging facility creates the logfile ~/.btsync/btsync-user.log If you encounter the forementioned problems (mainly startup problems after first boot), please post here the relevant part of the log file. TNX!!!!

OK Ladies and Gentlemen, sorry for the delay in solving this. I promise that tomorrow I will publish a modified /usr/lib/btsync-user/btsync-starter that produces meaningful logging output to debug these annoying issues with instructions how to apply it. I hope that we will find the cause for these problems.... I have also some good news: I'm working on something new. It's to early to tell about it, but I'm quite sure, that you will like it ;-)

Some news: after a few weeks from the latest release, it seems that some users encounter under certain circumstances problems with the autostart of btsync after login. The problem is described in Issue #60. Please take a look there, and tell me, if you find some clue for me.... Currently it is totally unclear what is the cause of this problem and under which circumstances it happens....

This seems really to be a problem related to the environment of your OS. I think that the next step should be to post an issue on the project page of btsyncindicator.py. UPDATE: The warning seems not to have any side effect on Debian Wheezy. In any case I posted Issue #41 - The problem is still unclear: the "sort of number 1 inside" (in fact it's an exclamation point) means that there is no connection to the btsync agent (or it is paused from the indicator menu that is basically the same). The reason why nemo crashes, is not really clear. Which distribution are you using?

Have you checked, that btsync on the linux machine is able to read and write the folders with the music? From your description, I understood that you installed the package btsync-user - this means that btsync is running under the credentials of the currently logged in user. You should check, that the music folder and all files you are synching are owned by that user or at least the permission of the directory and files allow the user btsync is running as, to create/read/write/delete the files....

The config file is fine. As I can see, it was generated correctly. Can you please describe again, what's exactly the problem on your machine?

Can you please post the contents of btsync-auto.conf ? Sigh.... We know. This is really ugly. Mark and me are really aware of this problem. It's documented in Issue #59, Issue #24 and Issue #32. The cause for this and some more problems is that btsyncindicator.py communicates with the background BitTorrent Sync agent by calling the web UI and parsing the results instead of using the BitTorrent Sync API. The reason for that was, that btsyncindicator.py was developed before the official release of the API. Currently there is still one blocking issue for Mark to use the API due to some unclear statements in the Terms of Use of the API. We are discussing about this issues with BitTorrent Inc. but we still have no final answer, so we have to wait for these issues being solved, before creating an improved version.

There are settings for both of these: during the first installation, debconf asks for the most important settings needed to install the daemon. If you perform a service reconfiguration, debconf asks for all available settings. If you perform a reconfiguration with sudo dpkg-reconfigure btsync you will be asked for the credentials and there you can specify both a user and a group of your choice for the btsync daemon. Additionally you will be asked also for a UMASK for the daemon. This setting determines with which mask files are created and written. In order to make all files and directories group writable, you have to specify 0002 One question: are you sure, that the server packages are the rights ones for your use case? If your Linux machines are used as regular desktop machines with a user that interactively logs in and wants to synchronise directories owned by himself, maybe the packages for desktop usage btsync-user may be more suitable for you.

Moved from wrong discussion thread... Are you sure, you are writing about the server version? I do not really understand, what is happening on your machine. Which old config file? No config file is updated during the update process of the software... OK. In the last release, there has been lots of changes and maybe some of those may be the cause of the problem. Since both me and Mark (the author of btsyncindicator.py) have no installation of linux mint and linux crouchbang, we have no way to test it on our systems. As a first step in understanding what's happening, I would suggest to try the following: Open a terminal, and execute the following command: btsync restartAfterwards post here the full ooutput that you see on the console and also the contents of the files ~/.config/btsync/btsync-agent.conf and (if present) ~/.config/btsync/btsync-user.conf

OK. Then you are in the wrong discussion thread. This is the discussion thread of the server version. Let's continue the discussion there, since it may be of interest also for other users.