jdrch

I'm running Resilio Sync with a Sync Home Pro license that is working perfectly across 2 Android tablets and 3 Windows PCs. Tonight I tried to add a Linux Mint 18.1 PC by copying and pasting the manual device link key from one of my Windows PCs to the Linux PC, but the latter's Resilio client still shows I don't have Home Pro. For some reason it's just not picking up the Home Pro license at all. Any ideas?

Fortunately the problem has been fixed in the most recent build. But prior to that the app would say display the "Startup" message, show 0 peers for all folders, and index folders when launched from the notification tray after the device was idle for a while instead of showing all online peers connected right away as it did previously.

I have my Android app set up as shown in the attached image. Yet, the app is still sleeping and therefore failing to sync immediately. I'm experiencing this on Android 7.0 and 7.1.2 devices. Any ideas? Help?

I think a note in the instructions about systemd vs. other things would be helpful.

I suspect part of the difficulty is different distros require different setup steps. It doesn't help that different distros also pull from different repositories, so even using the latter for distribution doesn't cover everyone.

Thanks for the guide; maintaining Sync on Mint is such a PITA I stopped using it on that platform. Just wasn't worth the effort for a PC I barely use anyway.

FWIW if you're using an Samsung S5, switch to CyanogenMod 13 and enable adoptable storage. This will give you trouble-free access to your SD card with full read-write permissions. It's what I use. I wrote a comprehensive guide on how to get CM 13 up and running on the Verizon S5 here: https://jdrch.wordpress.com/2016/04/17/how-to-unlock-the-bootloader-install-and-update-cyanogenmod-13-0-on-the-verizon-samsung-galaxy-s5/

I have Sync installed as a service on my Windows machines (great feature, thanks!). Is it necessary to manually stop the service before installing an update? Asking because I've had bad experiences with applications that run as services not installing correctly or borking their configs if I don't do that. Any ideas?

I'm pretty sure this is your problem. Sync by its very nature doesn't support concurrent changes across multiple peers. Also, Sync won't detect a change in a file unless it's saved, and I suspect how that's implemented varies across OSes. Reasonably sure that if you start over from scratch with the folder and save the .XLS files between edits, you should be OK.

I'm running Sync using the official binary on Linux Mint 17.2. I'm trying to get Sync to start when I login to the machine. So far I've tried adding the command ~/btsync/./btsyncto Startup Applications, but to no effect. Any ideas?

Thanks guys, that worked

Thanks! Where's that folder located?

I'm assuming the steps are: Kill BitTorrent Sync process. Download appropriate archive. Extract archive to location of previous version. Restart BitTorrent Sync process. Is this how it's done, or am I missing something?

So this issue (#4 here) was supposedly fixed in the 2.0.93 build, but it happened again today on my Windows 7 x64 machine. I had all my folders set to Sync All earlier in the week, only to find this morning that that setting was toggled to "Off".

Fair enough. FWIW since I disconnected and reconnected the trouble folders on phone all seems to be working.

From my experience the best (only?) reliable way to migrate from 1.4 to 2.0 is to remove all your 1.4 folders (including associated sync archive files/folders) and create new 2.0 folders. This is tedious, but the good news is there's no data loss and you're quickly back up and running until the Android app (currently a major PITA) throws an error and ruins everything again. I migrated to Syncthing today and am seeing how that works out.

No, it wasn't force closed. I have Battery Saver and Auto Sleep disabled; the client simply went to "idle" in the Android sense while in the notification tray. When I resumed it via tapping the notification, the errors appeared after the folders were loaded. As I said, 1.4 never had this issue. You could stop, idle, force close, and resume with no problem. So it would seem 2.0 is less robust for some reason.

Getting the following when resuming the Android (4.4.4) client (2.0.80.0) from idle: Syncing with Windows 64-bit 2.0.93 client on 3 other machines. I'm guessing the Android client may be choking because the folder contents were changed while the client wasn't running? Yet another issue the 1.4 client didn't have. Any ideas?

Here's what I get (running 2.0.93, Windows 7 x64 & 8.1 x64 machines idling and sleeping correctly):

1) Yeah that's what I thought. Thanks, the improvement would really make UX better. 2) The new Android is what I was referring to.

Bugs I originally posted about have at least been addressed to the point where I know have a working Windows machines + Android sync set up again. Thanks devs! That said, adding folders with many subfolders is still slow. I'm guessing the app scans the folder before it's actually added? If so, I would suggest this scanning process takes place after the add command is complete, i.e. the folder should show up as "Indexing" or "Pre-scanning" instead of the add dialog freezing.

My sentiments exactly. I freak out every time I see it. It's almost malicious, as if the app is punishing the user.

1) In the Android app, tap the options icon (...) for the disconnected folder. 2) Tap Remove. You will see a warning that says, verbatim (emphasis mine): I interpret the emphasized part to mean the folder's content will be deleted from my phone also, which is the issue I posted about originally. That's a really bad idea. The only rationale I can find for this behavior is the Android app was known to not support pre-existing folders by the developers from the start *head explodes with frustration and anger*. Rather than fix that horrific core problem, BT made the decision to address it with the Band-Aid of deleting the folder entirely (WHAT? You're joking, right?) so that subsequent re-adding would work, at the expense of having to re-sync the entire folder from scratch. This is the equivalent of bulldozing a house to fix a window. Even if that's what happened, it's extremely wrongheaded. There is absolutely no reason the Android app shouldn't support pre-existing folders; it not doing so defeats much of the purpose of Sync to begin with. Also, pre-existing folders were supported in 1.4.

Looks like I spoke too soon about @wimbit's solution. Woke up to "Unknown error: 110" on my S5 this morning for 3 of the 4 folders I'm syncing. *sigh* It gets even worse: even with my S5 on its own identity, trying to manually reconnect the folder using the "Add folder" menu gives a "106" error. Just communicated with Sync Help. Good news: an Android update is on the way that fixes these problems. Bad news: the bug was based on the ridiculous assumption that synced mobile folders would not be pre-existing, i.e. the mobile app supports connecting brand new folders only (WHAT? You're kidding, right?) I'm really scratching my head at the design/decision making process that led to the above. Update: I'm strongly suggesting Pro users who've been affected by bugs that prevent them from syncing to request pro-rated refunds http://forum.bittorrent.com/topic/34638-if-youre-a-pro-user-who-suffered-outages-due-to-broken-desktop-or-android-clients-request-a-pro-rated-refund/

Just reminding folks that since Sync Pro is a paid product, you're entitled to prorated refunds for periods in which said product doesn't work due to bugs. This is especially true for users of the Android 2.0 app, which has been broken since launch. So don't forget to request your $ back.