GreatMarko

You'll find the dedicated Wishlist for the Sync mobile app here.

...and what have you tried on your actual router itself?! - that may well be where your issues resides! (is UPnP enabled for your router?) That's correct Instead of using pre-defined hosts, try using the "Search LAN" per-folder option and see if you can establish direct LAN connections between your devices that way

Yep - looks an an issue with your router; specifically that your router is not correctly handling UPnP requests. Check your router settings (check that it supports UPnP and that that option is enabled) If you're unable to get UPnP working, see what "Listening Port" Sync is currently running on (Preferences -> Listening Port), and then manually allow that port through your router/firewall (Port Forwarding)

Which operating system are you referring to? ..and are you referring to thumbnails within folder's on the physical operating system itself that you're syncing , or are you asking for a "feature request" for thumbnails to be shown within the Sync UI? (i.e. in the History tab?)

Well, from your log, it looks like there's a problem with UPnP on your router, and also given your devices are in two different locations (i.e. on two different LANS, as you've not indicated that you have a VPN between them?) it's most probably that Sync is making relayed connections (rather than direct connections) between your devices. Relayed connections are generally a lot slower than direct connections (as they are "relayed" through an intermediary). Therefore, to improve your transfer speed: Resolve your router's UPnP issue(s) Consider setting up a VPN between your two locations so that your two devices in different countries appear as though they are on the same physical LAN

I think this was actually fixed for 1.2.82? That particular issue seemed to crop up in 1.2.73, indeed, I encountered it a couple of times in my testing of 1.2.73 too - but I've not encountered it 1.2.82 (or later), or heard of reports of others who have, so I would summize that it was indeed fixed for 1.2.82 back in November

Although on the syncthing site it does state that "It is currently far from ready for mass consumption, but it is a usable proof of concept and tech demo" ...so I would suggest that open source or not, syncthing is currently far less stable/usable than current builds of BitTorrent Sync! (which as of three months ago has over 1 million active users and had synced over 30 petabytes of data)

The time a folder was last sync'd is already shown in Sync:

Yes, if you're syncing between two computers only, they both need to be awake and online for syncing to take place between them.

The team are actively working on Sync 1.3. No recent beta builds doesn't equal no development! Around 60% of their development time goes purely to optimizing and improving the stability of Sync. Some issues require significant work and won't be noticed by the majority of users. However the team believe that the core value of Sync is fast and reliable synchronization and this remains their top priority. There are no new features in these builds, just bug fixes (such as this rather strange one related to the use of the number 9!). New features will come with Sync 1.3.x This hasn't been publicly revealed yet, so far as to say Sync 1.3 will add some "major features" Don't worry about the length of the Wishlist - the developers DO take note of all requests made in that thread, and they are keeping track of how popular and frequently requested each feature request posted there is.

I would suspect this is unlikely to be included as standard as a "default" rule in generated .SyncIgnore files, given that it is quite a specific use case, rather than a general rule that would relevant to a vast number of Sync users.

There are a number of reasons to explain the different in sizes/file counts - please see "Sync isn't completing - not all my files are synced / file counts don't match!" in the Unofficial FAQ

"check_for_update" is nothing to do with deleted/altered files - its a flag to denote whether Sync should check for newer versions of the software i.e. itself!

Firstly, do as Harold has indicated. If this doesn't resolve your issue, INCREASE the value "sync_max_time_diff", don't decrease it!! The default is 600 (seconds), meaning that Sync should still work if your devices clock's are within 10 minutes of each other. As you appear to have set this quite low (60), this means that all your devices would need to have clocks within a 1 minute difference of each other at all times for Sync to function correctly.

It is essentially bug fixes, like this one. New features are not expected until 1.3.x

You say the files are "identical" on both devices - does this include the timestamps of the files? i.e. when they were created/last modified?

Not at present, but it would be useful, so feel free to suggest it over in the wishlist thread!

Sync is currently in Beta, so yes! We can expect further performance improvements (CPU/Memory optimization, etc) in future builds

There are a number of possibilities to explain discrepancies in the file counts you're seeing: Check the exclusion rules that are setup in your .SyncIgnore files (excluded files/folders won't be included in Sync's file count)File counts in Sync won't include files in your .SyncArchive, (or any .SyncIgnore/.SyncTemp/.SyncPart/.SyncOld/.SyncID files)Sync can't access files if they're currently open/locked/in use by other applications.

Not if your router supports UPnP!

Well, a couple of things spring to mind; Firstly, there is a known issue with Mac operating systems not detecting/reporting changes to files in "real time", and therefore Sync isn't always able to detect changes "instantly", due to limitations of the underlying OS. Secondly, setting "folder_rescan_interval" to 1 second is not advisable, especially if you're syncing a large number of files/folders or large amount of data. Setting "folder_rescan_interval" this low can actually adversely affect the performance of Sync, and your computer itself. I appreciate what you're trying to do, but setting this value a little higher may actually help! The reason being is that Sync won't start syncing files in a folder until its index has been processed. If it's constantly restarting this indexing process every second (because folder_rescan_interval is set to 1), it may take longer to get to the files that have changed. But in all honesty, a 12 second delay between a file being changed and those changes being sync'd isn't all that bad on a Mac operating system, especially when you consider that Sync is still in "beta". Even on Windows operating systems, a delay of a few seconds between a file being changed and the changes being sync'd is quite normal.

I mean "folder" as in a folder you add to sync, which is then listed in the "Folders" tab of the UI. I would refer to the folders within each folder you add to Sync as "sub folders" ...or "share" meaning a device/node running Sync! I think my reply was pretty clear, but to clarify: If 8 folders are shown in your Sync UI (i.e. you've added 8 folders directly to your Sync, each with their own Secret), and you have "Search LAN" enabled for each of these 8 folders, I suspect you'll see x8 more multicast packets on your network (regardless of the number of sub-folders) than if there is only 1 folder shown in your Sync UI.

Sync currently can't currently be natively installed as a Windows service - although this functionality is planned. However, in the meantime, there are some workarounds - Please see this thread

I would suggest that the number of multicast packets being sent is directly related to the number of folders you've added to sync, given than the "Search LAN" setting (which is what produces these multicast packets), is a per folder setting. i.e. if you're syncing 8 folders, you'll see x8 more multicast packets than if you'd just added a single folder to sync. I agree this could certainly be better optimized than at present, but until then, if the amount of multicast traffic is causing you network issues, see my workaround earlier in this thread.

Do you really mean a "higher level", or a "lower level"? If you mean a "higher level" than the folder you're syncing (i.e. D:\ is a higher level than D:\Users), Sync won't sync that folder anyway! Sync will only sync the folder you select and lower (sub) folders. If you mean a "lower level" in the folder you're syncing (i.e. D:\Users\John is a lower level than D:\Users), then yes, you can use exclusion rules in your .SyncIgnore file to exclude certain files/folders from syncing.