pjssilva

Members
  • Posts

    8
  • Joined

  • Last visited

Everything posted by pjssilva

  1. Bingo, That is the problem, there is already an issue on this. I may try help debugging it this weekend.
  2. OK, I'll move the discussion to Mark's site. Note that I have upgraded recently to Ubuntu 13.10, this may explain some errors. I am writing this message now in another computer that is running 13.04 and it works well. Yes. To check this I added a line to the source code to print the information retrieved from the server (at line 249 of current source code). If I set bitsync web interface to English this is what I get (I ERASED the secrets): {u'folders': [{u'peers': [{u'status': u'Synced on 10/19/13 09:08:30', u'direct': 1, u'name': u'quorra -- pjssilva'}, {u'status': u'Synced on 10/19/13 09:07:55', u'direct': 1, u'name': u'trinity - pjssilva'}], u'name': u'/home/pjssilva/syncdir', u'iswritable': 1, u'secret': u'ERASED', u'readonlysecret': u'ERASED', u'size': u'112.0 MB in 168 files'}], u'speed': u'0.0 kB/s up, 0.0 kB/s down'}Look at the status result, it starts with "Synced", a string that is used in the code. Now, If I change the interface to Portuguese (Brasil), it becomes: {u'folders': [{u'peers': [{u'status': u'Sincronizado em 10/19/13 09:08:30', u'direct': 1, u'name': u'quorra -- pjssilva'}, {u'status': u'Sincronizado em 10/19/13 09:07:55', u'direct': 1, u'name': u'trinity - pjssilva'}], u'name': u'/home/pjssilva/syncdir', u'iswritable': 1, u'secret': u'ERASED', u'readonlysecret': u'ERASED', u'size': u'112.0 MB em 168 arquivos '}], u'speed': u'0.0 kB/s upload, 0.0 kB/s download'}Now, the status starts with "Sincronizado", which is synced in Portuguese. This was making the indicator behave badly until I switched it back to English. I'll add an issue about this in Mark's site too.
  3. Hello, I tried to start over my syncdirs and it looks better now. But I am having problems with the indicator. Basically it does not create the folders menu entries. It also tries to access the web interface every second, generating entries in sync.log. If I run it with DEBUG option I get many lines like this: INFO:root:Requesting status INFO:urllib3.connectionpool:Starting new HTTP connection (1): 127.0.0.1 DEBUG:urllib3.connectionpool:"GET /gui/?action=getsyncfolders&token=fGgmj9WlmTs-e3pjIgKGJHzZKmASiK5ittKN5VmSdHZaq29r7R3lYDblYVIAAAAA HTTP/1.1" 200 355 INFO:root:Requesting status INFO:urllib3.connectionpool:Starting new HTTP connection (1): 127.0.0.1 DEBUG:urllib3.connectionpool:"GET /gui/?action=getsyncfolders&token=fGgmj9WlmTs-e3pjIgKGJHzZKmASiK5ittKN5VmSdHZaq29r7R3lYDblYVIAAAAA HTTP/1.1" 200 355 Is this normal? Should I open a bug report somewhere? best, Paulo Obs: By looking at the code it seems like the indicator depends on the Language set for the web interface. So, avoidchanging it from English at least for now. Mine is in English now.
  4. It seems something got wrong with my syncdir. The indicator keep on circling, indicating activity. If turn on debugging the sync seems to be going forever. I don't know how to exactly read the log (see an excerpt below). I had the same problem in my laptop. There the solution was to delete the syncdir, and the bit-sync configuration and start over. Should I do the same in all machines? Maybe something changed in the file formats? best, Paulo [20131018 07:27:16.475] Merge: processing root message, remote hash DB93E3BF29E3E815DBBF98DC4EED097D6648A43B, timediff: 1 [20131018 07:27:16.475] Merge: sending get_have_pieces, prevhash: 7BE6D5022D1E44A8691DB101DD898F3F32BC648A [20131018 07:27:16.564] Merge: processing have_pieces message [20131018 07:27:16.564] State sync finished for folder /home/pjssilva/syncdir [20131018 07:27:17.064] Sending broadcast ping for share 5CDD8537F50E14F43072C04E9C9F47663CB4BF85 [20131018 07:27:17.090] Got 2 relay ips [20131018 07:27:17.090] ip 67.215.229.106:3000 [20131018 07:27:17.090] ip 67.215.231.242:3000 [20131018 07:27:17.240] Got 3 tracker ips [20131018 07:27:17.240] ip 54.225.196.38:3000 [20131018 07:27:17.240] ip 54.225.100.8:3000 [20131018 07:27:17.240] ip 54.225.92.50:3000 [20131018 07:27:17.257] HTTP: IP 127.0.0.1: GET /gui/?action=getsyncfolders&token=ijDv5OOHYbLEyxJcDa9ot1Qu1-IiqAJuWru1MWmH2U4rn-L1k-9p754LYVIAAAAA [20131018 07:27:18.257] Sending broadcast ping for share 5CDD8537F50E14F43072C04E9C9F47663CB4BF85 [20131018 07:27:18.258] Requesting peers from server [20131018 07:27:18.416] Got list of 2 peers from 54.225.92.50:3000 [20131018 07:27:18.416] Peer 0: 143.106.XXX.XXX:54068 00CB0E2AB731D1A7F15B43C9F003B33BE133DBF2 [20131018 07:27:18.416] Peer 0: local IP 143.106.XXX.XXX:54068 [20131018 07:27:19.258] HTTP: IP 127.0.0.1: GET /gui/?action=getsyncfolders&token=ijDv5OOHYbLEyxJcDa9ot1Qu1-IiqAJuWru1MWmH2U4rn-L1k-9p754LYVIAAAAA [20131018 07:27:19.258] Sending broadcast ping for share 5CDD8537F50E14F43072C04E9C9F47663CB4BF85 [20131018 07:27:20.259] Sending broadcast ping for share 5CDD8537F50E14F43072C04E9C9F47663CB4BF85 [20131018 07:27:20.259] Send ping to peer (00CB0E2AB731D1A7F15B43C9F003B33BE133DBF2) for share 5CDD8537F50E14F43072C04E9C9F47663CB4BF85: [20131018 07:27:20.259] ping 143.106.XXX.XXX:54068 directly It goes on and on...
  5. Hi, tuxpoldo. I have tested your solution to the multiuser setup and it is working great in my laptop. Good job!
  6. Here is my Python script to workaround the discussed problem in machines with multiple users. It implements the work around described above. It must be run as root. Disclaimer: I do not take any responsability for any damage made to your system by this script. I am giving away its code, anyone can read the code and verify what it does. Obs: I had to zip the file to be allowed to upload it. The zip only has the Python scriipt. btsync-workaround.zip
  7. First, please enjoy your honeymoon and don't bother with this until you come back :-) And congratulations! I am not sure if this is what you want. But you can store specific user desktop files that will overide the default one by placing them at ~/.local/share/applications. So a possible solution to the problem would involve two ingredients: 1) Make the default/automatic configuration (~/.btsync.conf) point the web interface to port 8999+uid (or something along those lines). 2) Create custom .desktop files for each user (probably at login time) putting them in ~/.local/share/applications pointing the browser to the right port. I will try today to write a simple Python script that will solve my problem statically by: 1) Copying the ~/.btsync.conf to ~/btsync.conf and chaging the port. 2) Copying the default .desktop file to ~/.local/share/applications and setting the right port. I'll write back to say if this is a good workaround and attach the script for other to use in the mean time. You are right, I forgot about that. Thanks.
  8. I have problems with multiple users, but I am not certain if it is related to the way it was packaged or not. My computer is shared by my family. In particular even my personal laptop is sometimes used by my wife. Yesterday she logged in for the first time after I had installed the desktop package of bitsync. Bitsync than started in her session and it started using 100% CPU. It seems that the problem is that there is another bitsync instance running for my user and both are trying to add a simple web server to listen to the same port (9999). When the secondd btsync-agent tries to attach to the port that is already used the CPU gets maxed out. I checked this by manually modifiying my configuration to add the web server at port 10000 instead of 9999. With this configuration both instances can happily coexist. Maybe bitsync could (or even should) use a different port for each user? Something like 8999+uid ? In this case the launcher for the bitsync web interface should also be modified. Another problem is that one user can look at thee name of the directories being shared by the other users in the default configurartion as no password is required by default. This maybe considered a small privacy problem. Obs: edited to fix some typos.