JimmyTheSaint

To be clear: the 110 error happens every single time, 100% of the time without fail, within minutes, on each and every share, regardless of its size or number of files. The 110 error appears to happen as a result of the phone sleeping, which it constantly has to do. In other words, it always and constantly occurs until I reboot my phone. Upon reboot, the phone overwrites all the other clients with its old files. So re-adding the folder won't help because such a fix would only last for minutes and then lead to a data disaster. Your workaround for Linux is truly disheartening because you're saying the full version of 2.0 can't be used on Linux. I didn't see any announcement at the start that 2.0 doesn't work on Linux. Was there a notification that makes this clear to Linux users? So you're saying I'm once again segregated from 2.0. Can Android be set up with 1.4 folders while using 2.0? Is that expected to fix the 110 error? How do you do a clean install of 2.0 while specifying 1.4 folders? If 1.4 folders can be used on Android's 2.0 as a workaround, then once again, I'm segregated from 2.0.

Sorry to pile on the melodrama while emotions are otherwise running high, but I can't see my situation as other than depressing: I've been syncing a small folder of 2MB and 23 files between my Windows clients, Linux NAS and Android S4. Only the Windows boxes sync properly, the Linux NAS won't transfer any data, and the phone keeps reproducing the disastrous old-overwrites-new problem. On my S4, I have "Battery saver" and "Auto-sleep" turned off. I'm WiFi only with no data plan, so "Use mobile data" is unchecked. At first everything works, but I always eventually get "Unknown error: 110" on every sync folder. My Windows clients then show the Android peer online, and that it's still syncing the latest changes, but sync never proceeds. I also get the same situation with camera sync: I make a test photo or two, and it works fine at first, but then it soon goes 110 and stops syncing even though the Windows peers see the phone online. Rebooting the phone is the only way I've found to clear the 110 error, and then the phone syncs with the Windows laptops. The phone then clobbers all data updates since the last time it synced: in other words, when rebooting after a 110 error, the phone overwrites new with old. That's a total dealbreaker, as my phone must reboot quite often to accommodate updates to certain apps, let alone ROM updates. Of course, I don't dare trying again to connect the phone to the two other large folders that I'm syncing on my Windows boxes, But when I did try that, the S4 transferred data at a snail's pace, and then 110'ed before syncing even 1% of the files. Syncing my phone ran at expected speeds on my home LAN with 1.3, and it looks like I'm once again forced to downgrade to 1.3 as the last working version I've ever tried. That will make periodic testing of updated 2.0's quite a chore because I would have to do clean installs of 2.0 on multiple devices and then likely downgrade again after the test. 2.0 also totally fails to sync on my Linux NAS, though I currently suspect that may be a firewall issue due to change in port usage from 1.3 to 2.0. I really can't test that as I have to bail immediately from 2.0 so that I can use BitTorrent Sync on my phone. If anyone has a constructive suggestion, I'd appreciate it. Otherwise, I have to return to the 1.3 ghetto with virtually no hope of upgrading, and where it will be more and more unlikely to get support, which blows.

This is different enough from my other "110" thread that I'm making it a separate topic. As described in my other "110" thread, I've synced a 2MB, 23 file folder no problem (though I frequently have to fix its 110 problem by rebooting.) But my 8GB folder of 23,000 never syncs. At first, it syncs at a super-slow pace on my home LAN, whereas 1.3 would eventually go at 2-3Mb/s as expected. But 2.0 gives me the 110 error after replicating the tree structure, but transferring only a few hundred files. The Android client will then show as syncing on my Windows clients, but no progress is made. Even worse--and this is why it's a separate thread--my S4's CPU runs at a constant 30% when it normally idles at 7% or less. Clearly, BitTorrent Sync is doing something, but this is infinite loop behavior. Meanwhile, my diagnositc app (3C Toolbox) doesn't even list the BitTorrent Sync app in its list of running tasks: it shows 30% CPU usage, but the list of running tasks only accounts for a few percent of CPU usage. I've tried clean installing on Android a few times, but it's the same issue every time--it looks like the Android BitTorrent Sync app goes totally haywire

This is an informational question, not a troubleshooting question. I just want to find out if anyone has seen "unknown error: 110" on Android and I'd like to get the definition of this error.

I specified a folder on the external SD card as the default folder when first adding my phone as a device. It synced one small folder correctly. I have a large folder that it starting syncing extremely slowly (much more slowly than 1.3), but it stopped making progress after 600 out of 20,000 files. Now both folder just keep showing "Unknown error: 110."

I'm doing my initial 2.0 setup with everything on my home LAN. I clean installed on one Windows laptop, then clean installed on a second Windows laptop, adding the device key supplied by the first. It syncs, no problem. Then I run btsync on my Synology DS213+ NAS where I have a shared folder properly set up. At the initial setup, I supply the same key to link devices, and everything appears to be fine, except it finishes syncing instantly and then shows the size of all four of my sync folders as 0 KB. Everything looks correct, and each sync folder contains its properly set up .sync directory. Each Windows client correctly shows the extra peer online. The Linux btsync process shows nothing unusual in its CPU usage, which is very low, presumably because it thinks there are no files. I've tried clean syncing the Linux box two times, now, but it's the same result. Any troubleshooting suggestions? UPDATE: at this point, my Windows clients show the Linux peer offline and all the data waiting to upload to it.

That's something to look forward to, then. But it would be a nice feature if we could manually control the parameters around deleting peers.

You're a detective! thanks

In the 2.0 Windows and Linux clients, I can't find a version number specified. I'd have expected to find this info in an "about" menu item.

With 2.0, I synced my Android phone with my Windows clients by manually adding folders one at a time. I then had some issues, so I disconnected the phone's sync folders, uninstalled the Android app, and rebooted the phone. My Windows clients still include the Android client in the "Peers online" count, indicating the phone is presently offline. How do you get a client to permanently forget one of its former peers? I mean, I really don't want my current devices to accumulate a list of all the devices I've ever synced indifferently to their present status.

Is there a Linux version somewhere?

Oh, I see it now: the three-dots menu in the My Devices pane. I had been trying Settings>Identity details. I would think that allowing to change the device name under settings is at least as intuitive as under My Devices--perhaps allow both places? Eh?--2.0.44 just let me change numerous times. I only did a quick install to re-check the renaming ability, and my phone has no other 2.0 peers. EDIT: crap, I just realized that 2.0.44 upgrades and doesn't do a parallel install. So now my Android is running 2.0.44, but my Linux and Windows devices are all 1.3.109. Android 2.0.44 marks the syncing folders as "1.4" and it appears to be working correctly, propagating the device name changes as expected, but showing none of the external devices in the My devices pane. I sure hope Android 2.0.44 is compatible with 1.3.109 as well as 1.4.

The "Camera backup" enable/disable switch remains permanently in my list of folders, even if I never want to enable it. That's annoying to users who never intend to enable it, and I'd hate to accidentally touch the enable switch and start a data transfer that I then have to clean up. While it's alpha and I'm still running my "production" 1.3 version that syncs my camera folder, I'm never going to enable camera backup in the alpha version. So the sooner I can hide that option, the better.

I'd like to provide more obvious, user-friendly device names for my Android devices. For example, "S4" instead of "GT-I9500." The default on Windows is OK because it's the name I've given to my computer. But the Android device name apparently defaults to what the manufacturer has named it, and those names are hard to track.

OK, but I just tried reading history.day with Ultima's BEncode Editor, and it's basically useless for reading history this way to do the necessary bookkeeping to verify if anything's been lost and to restore stuff. We either need a history reading utility that will make history as readable as in 1.3 or a conversion utility that will convert history.dat into a ledger that can be used in case of a disaster or a suspected problem.

I've complained about how the history has been difficult to use in 1.4 and 2.0. If everything just works, however, there's no real need to ever bother with history. In fact, I believe Syncthing doesn't have history at all, which is quite unsettling at this stage of development. But history is the ultimate safety net for when things go wrong, and is an essential sanity check if you ever lose faith. So perhaps history is more of a feature for geeks than the average user. In that case, why not maintain a history file in the same place as the log, but separate from the log, which contains way too much info? When faced with a restoration session (my only real use for history), I'd much rather refer to a txt file than the history window because bookkeeping is much easier that way. For example, in the past 18 months, I've done 8-10 restoration sessions after old-replaced-new episodes arose due to faulty interactions among my peers (usually the Linux client's btsync starting up hours or days after a reboot shut it down). In 1.3, using the history tab as an index to restore stuff from the archive is usable, but a bit of a pain to follow because the history tab automatically updates and scrolls after each file is manually replaced. Providing a history file would make that much easier, while maintaining a safety net that stays out of sight and out of mind until needed. In fact, I haven't had to do this in quite some time (knock wood) because negative reinforcment has made me much better at remembering to manually restart my Linux NAS's btsync. The main UI's history window would still be useful for monitoring the most recent entries, I suppose. But it's not really all that useful to me because you can't leave it open as a real-time monitor like 1.3--it has to be manually refreshed by closing and re-opening it.

D'OH!! Of course, you're right. That's got to be my doofus move of the year. Please ignore the OP's feature request.

As a single user who only shares among his own perosonal devices, I have a much simpler share structure: six folders. Always showing the full path displays useless information. The only useful information for me is the last component in the path, which is the folder name. So the full path name column crowds out other information and/or makes the window too big. In 1.3, for example, we only see the Folder column and have to hover the mouse over the folder name to get the full path. I never hover the mouse because I already know all my full path names. I'm asking for the option to add a column that shows the shared folder without showing the full path, not to get rid of the option to show the full path.

Showing the full path name in a column is mostly unnecessary for me. Because the full path name takes up so much column real estate, I'd rather just show the folder name.

Dropbox stores your data on their servers, too. Those services basically provide a server that's up 24/7 so that you don't have to. I found quitting Dropbox a no-brainer because my phone stayed on 24/7 and acted as the 24/7 server (unlimited data plan) so that everything else would be guaranteed to sync as soon as it was switched on. I also had a backup phone that stayed up 24/7 on my home LAN's WiFi, so that was two 24/7 servers. Dropbox was just a waste of money, and then the whole Snowden thing hit. Of course, I also have a couple of 24/7 NAS's, so I don't need to rely on my phones and I've now quit my data plan because there's so much free WiFi available. But it seems to me that keeping one device on 24/7 can be convenient enough if you can use your phone's data plan.

I did the same thing. IT investigated and found BitTorrent Sync OK, so they unblocked it, but only for my location. I think it's more work or maybe difficult for them to allow bt protocol while still disallowing unwanted file sharing. Perhaps you also have to clear a port number with them so that they can separate the different kinds of uses.

Can you post specific CPU usage stats? On my NAS, 1.4 increased CPU usage significantly over 1.3.109. Was there a big improvement with 1.4.93 over the previous 1.4's?

Having run into problems the first time, I was also planning to do a clean install when I upgrade to 1.4. One issue I had with 1.4 was higher CPU usage on my Linux box while btsync was between sync times. What kind of CPU usage are you seeing on your Linux box as compared to 1.3.109?

To ensure that Android apps don't update themselves, I use the app 3c Toolbox Pro to unlink such apps from the Play Store. The Play Store's auto update settings don't always seem to work as expected, perhaps when the Play Store updates or as the result of updating my ROM. Once unlinked, they continue to run normally, but Play Store has no idea that they're installed. I think the link gets restored, though, after a ROM update.

For my manual installation of btsync, I naturally had to create a btsync user. I only ever start the btsync process while logged in as that btsync user, launching the binary that lives under that user's home directory. So of course that btsync user owns the process, and everything else runs correctly, with no access or permission errors. If you're suggesting somehow attaching a new user to the community package's process, I suppose there must be a way to finagle permissions, but I suppose you'd have to be confident you know every single thing that the process accesses, which I wouldn't be. So I wouldn't want to mess with any confusions arising from that hybrid situation. I believe I did once try the community package and then bailed when it didn't give me enough control, particularly for updates and reverting. There was a manual installation guide available, so that's how I've always done things.