bwainscott

I just updated to 1.4.103 on my Linux system (stopped 1.4.93, started then started 1.4.103 with the same config file) and it came up with a "welcome to BTSync" page and then tells me I have no shares at all. I think this happened when I updated from 1.4.91 to 1.4.93 also. I'm sure this is not expected behavior -- so what am I doing wrong?

I'll post below the script that I run via cron. It is of course specific to my setup, which looks like this: On my RPI, the directory /home/pi/BTInstall is the share where it expects new executables to show up. It expects them to be named "btsync_arm-X.Y.Z.tar.gz". My running executable is in /usr/local/bin/btsync, and is a symbolic link to the actual executable, which is /usr/local/bin/btsync_X.Y.Z I use the same script on my laptop, which has similar setup but different "install from" directory. The script takes a single argument: if it == "pi" then it does everything silently and with the appropriate settings for my RPI. Otherwise it is running on my laptop interactively, and it lets me know what it is doing. Here is the script: #!/usr/bin/python # Takes one optional argument. If "pi" then am on my pi, else on laptop import sys import os import stat import time import signal # if(len(sys.argv) < 2 or sys.argv[1] != 'pi'): onpi=0 else: onpi=1 # # Directory to look in, and filename to look for # if(onpi): SYNCDIR="/home/pi/BTinstall" LOOKFOR="btsync_arm" else: SYNCDIR="/home/brian/Downloads" LOOKFOR="btsync_x64" # # for chmod call below, to set rwxr-xr-x # mode=stat.S_IRUSR | stat.S_IWUSR | stat.S_IXUSR mode= mode | stat.S_IRGRP | stat.S_IXGRP mode= mode | stat.S_IROTH | stat.S_IXOTH # # Go to where the file should be, and get a directory listing # Sort it in case there is more than one btsync_* -- install # the oldest. # os.chdir(SYNCDIR) files=os.listdir(".") files.sort() for t in files: if(len(t) > 10 and t[:10] == LOOKFOR): # if(not onpi): print "Installing %s" % t # # expect name like btsync_arm-X.Y.Z.tar.gz (arm or x64) # this pulls out the X.Y.Z # name=t.split("-")[1][:-7] # # See if btsync is running. If so, stop it, wait to be sure, and set # flag to restart it # restart=0 f=os.popen("ps -e","r") for p in f.readlines(): parts=p.strip().split() if(parts[-1] == 'btsync'): os.kill(int(parts[0]),signal.SIGTERM) time.sleep(30) restart=1 break # # Put new executable in place # os.remove("/usr/local/bin/btsync") os.system("tar -xzf %s -O > /usr/local/bin/btsync_%s" % (t,name)) os.chmod("/usr/local/bin/btsync_%s" % name,mode) os.symlink("btsync_%s" % name,"/usr/local/bin/btsync") # # Remove the file we installed, and optionally restart btsync if(restart): os.system("rm %s ; /usr/local/bin/start_btsync" % t) else: os.system("rm %s" % t) sys.exit(0)

I also have a RPI as my "always on" sync system, with an external 1TB drive (attached via a powered hub -- the RPI definitely does not supply enough power to connect it directly). It works quite well, but I must confess I do not tax my system at all. I sync our digital photo archive, recipes, my music, the pictures from both my phone and my wife's, and not much else -- and none of this changes often. I have 2 laptops (one Windows 7, one Linux), two Android phones, and the RPI. The RPI is essential since the others can never be guaranteed to be on at the same time. I got tired of logging in to the RPI to update the btsync client with each new release, so set up a cron job on a 10 minute schedule, that checks a particular share for a new "btsync_arm" executable. If it finds it, it stops btsync, installs it, deletes it from the share, and restarts btsync. I only had an opportunity to try it for the first time when going from 1.3.87 to 1.3.93, but it worked great -- I just downloaded the btsync_arm to the share on my laptop, and 15 minutes later my RPI was running the new version (and had deleted the file from the share). Computers are so much fun when they work correctly!

When my PI didn't see the shares from the laptop, I tried unshareing and reshareing it on the PI, and even created a new secret on the laptop -- nothing helped. I think I stopped and restarted sync on the laptop a couple of times, but I was focused on the PI, thinking it was the problem (seems I was wrong in this). I may be able to duplicate this and grab some logs, but it won't be before tomorrow night at the earliest.

Similar problem here. Two computers on the local network. One is also visible from outside (my always on RaspberryPi) and the other a Windows laptop. Three shares on the laptop were "Search Lan" only (all shares on the PI are "use tracker"), and two of them wouldn't sync to the PI. (Everything on the PI is "Read only" in case that matters.) I wasn't sure what the problem was, and my wife would want to kill me if I destroyed 10 years worth of digital photos (syncing to the PI as backup), so I downgraded everything to 1.2.92 which has been working perfectly for me. I also had one old file reappear on the laptop with the 1.3.67 upgrade -- it didn't overwrite anything because it had a unique name (I had just deleted it a copule of weeks ago), but it was disturbing enough to scare me. Hopefully these issues can be resolved soon -- looks like there are a lot of good updates in 1.3. (Unfortunately, no logs of the above problems).

Please add "predefined peer" support to the android version for those of us with always on servers. Thanks

@vadimt: Will Android 1.2.14 ever hit the Google Play store? I have 1.2.12 installed, and the Play store has the "What's New" that includes 1.2.14, but insists I'm up to date. I don't know if it is possible, but it LOOKS like they updated the comments without actually updating the executable? I know I can install directly from the apk file linked on the first page, but was waiting to use the Play store and it has been a couple of days now. Thanks.

spiderben25: Sorry I didn't see your posts earlier or I would have suggested this. I had similar problems going from 1.1.X -> 1.2.X on my Raspberry PI: it got stuck indexing and wouldn't stop. After deleting the sync folders (keeping the data!) cleaning out all .Sync files from those directories, and then adding them again, it synced in about 2 hours and has been running fine since. I think there was something wonky about the 1.1->1.2 upgrade. I haven't had that problem upgrading between 1.2.X versions. I'm glad you got it straightened out.

Excellent! When I get home later I'll replicate my problem and do this

Nope -- no difference: when I take a picture with my phone, the laptop shows a file added and more data to be downloaded from the phone, but no data comes. When I added a file on the laptop (different share), it synced to the Pi right away, and to the phone a couple of minutes later, but the phone still has not updated the pictures I took to the laptop. It definitely seems to be an issue with the phone pushing data to the other clients. Hopefully the logs I sent them the other day will tell them something. Is there any way to collect debug logs from the Android to send them? I don't see anything in the app, and they only describe how to do this with Windows/Linux/IOS, but I expect they need to see what is going on on my phone...

Thanks Jimmy -- you're a saint. I only got my first Android phone a few months ago, and it never occurred to me that it was even possible to install apps from other than the play store without rooting my phone. Unfortunately, I seem to be still having the same problem: when I add a file on the phone, my laptop and Raspberry PI show it added and trying to download, but they don't transfer any data. Eventually it will show up, in a few hours, at least that is the way it has been. I'm running 1.2.67 because the changelong for 1.2.68 didn't seem to indicate anything related to this got fixed. I guess I'll upgrade them anyway just to see if it makes a difference. And I'll keep my eye on their download link for Android updates instead of waiting for the play store.

1.2.10? The google play store still has 1.2.9, with which I'm having the same kind of auto sleep behavior you were describing (30 minute sleep, but changes taking sometimes several hours to sync). That is good news -- I'll definitely be happy to get the new version.

It was/is set to automatic. I sent logs to support. Hopefully they can quickly resolve this

I just mailed a detailed description and some debug logs to syncapp@bittorrent.com. I installed the 1.2.9 app this morning, and it is still not syncing when I add files.

The re-initialization worked just fine. I stopped and restarted btsync on the PI, and it re-indexed in just a few minutes. Seems to be working fine now -- was probably related to the 1.1 -> 1.2 update somehow?

I will if I run into more trouble: last night I got impatient and "unshared" all the folders in my PI, removed the .Sync* files/folders, and set them back up to share again. All the shared folders are read-only on the PI and I didn't think about the fact that it would need a source for reinitialization, so I closed my laptop. So it only got about 1.9G (750+ pictures) indexed before I went to bed, and was stuck there all night. I thought "Ah, a 2GB boundary issue" -- shut down btsync, set up the debug.txt for the log file, and restarted it. Now that the laptop is up, it is humming along. At the rate it is going, it should either be done or stuck in a couple of hours. If it finishes, I try stoping and restarting it. If it hangs, I'll send the end of the log file. In any case I'll definitely let you know. And thank you guys for a very useful program. While I have your attention: any chance of adding "pre-defined hosts" and "don't use tracker" for the mobile app? For folks with servers running this might be a nice option -- I'd certainly use it. Thanks again!

I added it as a shared folder. Unfortunately, it seems intermittent? Yesterday afternoon I took picutres a couple of times and was careful not to touch btsync (which was running in the background). When I got home, they had uploaded at what seemed like reasonable times. I was moving in and out of wifi coverage at the time (and had mobile data turned on), so maybe network changes triggered it? I'll be at home all day today, so will test it some more and let you know if I can figure out anything reproducable.

Android and sleeping: I like the idea of the "wake up every 30 minutes to see if there is anything to do", but I'm not sure it is working. I have my phone set up to share my camera folder. But I've taken pictures (while btsync is running in the background) and then waited several hours and they have not synced to my other systems. If I then bring btsync to the foreground, it seems to wake up and send everything. Any suggestions? Is there anything I could send in in terms of logs that would help debug this?

I updated my raspberry pi last night, and it is taking FOREVER to re-index. I have one share with about 20K files in it totalling 53GB. On my windows laptop, that share indexed in a few minutes (10?). My pi indexed all night. Then I stopped btsync and restarted it. That was 11 hours ago now, and it is still indexing. Now granted, it is not a particularly fast machine, but with previous upgrades the reindexing took maybe an hour or two. Is there any way to tell what it is doing, how it is progressing, or when it might be done?

Pre-defined known hosts for the mobile client: I'd like to put in the DNS:IP of my server and possibly disable tracker use on the mobile client. Among other things, if the bittorrent trackers ever went dark, btsync mobile would still work.

I also experienced some problems with the new Android app. One of my servers is still running 1.1.70, and one the new 1.2.67. I have 4 shared folders on my Android, two set to auto-sync and two not. After the update, one of my NOT auto-sync folders was fully downloaded to my phone. Fortunately it was not the one with the 100MB of data, (only about 3MB). Sorry no logs -- I wiped out the folder and set it up again. Now the Android is reporting 0 devices online and not transferring anything. I'll try to collect some log data tonight. Just stopped and restarted the Android app, now it sees 2 devices and .... now it sees 0 again. UPDATE: seems to be working now. I unsync'd all folders, uninstalled btsync, removed the SyncIgnore files (SyncID were already gone), reinstalled and set up sync on all the folders again (all this on my Android). It may or may not matter that I also updated all my other machines also, so everything is running the latest versions.

Too bad there is no option for this for the mobile client. I know they expect the mobile client will normally be "out and about" and so using the tracker would be the common usage. But I'd still prefer the OPTION of turning it off and setting up pre-defined hosts. Sounds like something in the newer versions doesn't play well with their 'tracker' server. Because I don't know how to downgrade my android phone, I'm SOL until they post a fix to the play store.

Same here. I updated hoping the "sleep" feature would allow me to leave it on all the time and not drain the battery. I set it up to sync photos from my phone to my laptop, but it seems totally broken. I turned the sleep off but that didn't make a difference: the laptop shows the phone created some files, and it is waiting for 8mb of data from the phone, but that data never comes. Starting and stopping btsync on the phone does not help. Surprisingly, rebooting the phone DOES help -- when btsync starts back up the files go right across...but then I try some more pictures and it hangs again. Anyone know how to downgrade the android app on my phone?

I'd like to be able to re-download a file in a read-only share. Here is the situation: Suppose I have 10GB of music in a shared folder on my server that I sync to my phone as read-only. I don't have room for all of that on my phone, so I only sync over an album or two. When I get tired of that music, I delete it from my phone and sync something else. I have shared it to my phone read-only, because I don't want to actually delete any of it off my server. But now I can't go back and redownload the original albums I deleted off my phone, because btsync sees that I deleted them locally, and assumes I'll never want them again. I understand that this behavior may make sense for a normal read-only workstation client, but I'd rather the mobile app be different in this respect. Actually, what would work for both would be a "forget I ever deleted these files" option or something along those lines.

Just downloaded and installed 1.1.21 from the play store. Looks great, but I do have one question/problem: I set up a shared folder of pictures, with automatic sync turned off and the phone set as a read-only sharer. This would be perfect for having access to things when on the road without carrying them all around. I picked one and it synced just fine. Then I deleted it off my phone and now I can't sync it again. It shows up on the "remote" tab with a bar underneath the entry, and which I pick it nothing happens. I picked another picture and it synced just fine, but any one I sync then delete I can't sync again. Now, I can understand how with a normal btsync client in read-only mode, if you delete something locally that means "I don't want to hold on to a copy of this -- don't send it to me" which is fine. But for a mobile device I think it should be different -- particularly if I specifically ASK for another copy to be downloaded (ie, I pick it), which it seems I can't do. I'd say this is a bug, and a definite usability issue. I tried deleting the .SyncIgnore file (while btsync was not running!), and it didn't make any difference.