RomanZ

@Baz_Singh Please check your firewall settings on desktop. It should not block incoming connections to your listening port, as well as to port 3838. As a test I can share a test folder with couple of files with you - check if your iPhone will manage to connect and get files.

@Freekers, Did you had any chance to get core dump?

@Baz_Singh I suggest that your laptop is running 2 network interfaces simultaneously. Try using only one of them and see if it helps.

@lchoquel, As I see you've got a log analysis report from our Support Team. For the all other people: when BTSync is not working, it can't monitor the changes happening to Sync folders, and can't precisely record the time when file was updated by user (or user's app - like Dropbox, office, etc.). So, if file got changed by something when BTSync is off, the change considered to happen when BTSync is started again.

@poilu29@gmail.com, Here are the options I can suggest: 1. The folder which does not sync content was added to .SyncIgnore 2. Permissions issue (I suggest installing some Terminal application and checking permissions for the folder) Try adding this folder to BTSync explicitly - and see if it syncs. If all of the items above does not help - could you please tap a "Feedback" on your phone and agree to send logs? Our support can take a look at the logs and understand why your screenshots folder is not synced.

@jemail Actually there are no limitations for 8.3 names - until WinAPI allows BTSync to read the file, it will be synced. I suggest providing full debug log so I can find out what is happening.

@maba The mechanism of local peers discovery has changed in 1.3. Did you upgrade from 1.2 to 1.3? Can you please turn on debug logging, turn on both computers, wait for couple of minutes and upload logs to me?

@skeezix This is basic functionality, and the fact that deleted/removed files reappear looks to be a bug. I suggest you and your friends are using the 1.3.94 build? If issue is still present - I would appreciate getting debug logs, which might contain the traces of the issue.

@ronenb BTSync is pure userspace application which is very unlikely to cause whole computer freezing. Can you please check: 1) If shutting down the BTSync before moving your laptop to standby resolves the issue 2) Which amount of memory is consumed by BTSync, which amount of physical memory is installed on your PC, how much files / folders do you have in sync folder?

@gibby916, The message you put in subj actually means - no error, everything is okay. As your asymmetric connection is pretty slow - 20Mbit for download, the HDD is very unlikely to be the bottleneck. I can suggest 3 more places which throttle the traffic: 1) your Windows firewall. Give it a try - disable it for couple of minutes, and see if issue persists 2) your ADSL modem. Some modems do not process well massive UDP traffic and either crash or throttle it. 3) your ISP. Some ISP providers throttle massive UDP traffic. for 2) and 3) - do you have a uTorrent client on your Win8.1 machine? is it working fine?

@KerberosDY Can you share more details about your peers that do not see each other? Are they in LAN or connected over Internet? In any case, debug logs are highly appreciated. @eazq If several peers are available - BTSync benefits from both of connections getting data from both peers (until download bandwidth allows). Could you please describe your scenario, what do you see and what do you expect to see? @cubik Do I understand correctly that at the end of day you get: - a synced folder on 2 peers - some data is unique to peer A, some - to peer B (due to .syncignore - as designed) - you start the auto-update, and during auto-update .syncignore is not counted anymore - which forces unique data to be synced between A and B - and after upgrade the unique data gets deleted? Please correct me if i'm wrong.

@omata As I understand you have several peers in the office (different VLANs) and one peer at home. Can you please try to reach the file "http://config.usyncapp.com/sync.conf" from your peers? It looks like your peers can't contact the tracker server - and the location of tracker server determined by the conf file I mention above. @softea Most likely you have a different issue. I guess that your UI states something like "Cannot sync due to time difference more than 600 seconds" - which means that you either has a wrong time on one/multiple of your peers OR you have a wrong timezone set. Please check your time and your timezone. @neiaberau The devices you expect to see - are they in LAN or connected to the internet? all Indeed, 1.3 has a different mechanism of devices discovery and communications. It generates much less redundant traffic and designed to be faster.

@jtholb, I suggest you tried the latest version of BTSync? 1.3 has a dramatic improvement: it uses TCP connection to transfer data, while DNS still based on UDP (this is actually the only point I see where they can intersect).

Just a 5% of a bandwidth - it is definitely not a HDD bottleneck. And BTSync is not that nice, it should try to consume more of your bandwidth. Unfortunately it looks like you encountered a speed issue we are trying to resolve right now: in rare occasions BTSync does not get the whole bandwidth with no obvious reason. I suggest to keep an eye on forum topic below - I'll publish news about speed issue resolution over there. http://forum.bittorrent.com/topic/25217-inconsistent-speed/page-2?hl=%20inconsistent%20%20speed Answering your questions: - "Playing nice" to other apps can't be adjusted. But, as I mentioned above - it is not that nice, you have a different issue. - BTSync uses the order of files defined by OS itself. Thanks for the randomization idea - we'll consider it for future releases.

@dixonbg This is a sort of "one-way sync" feature. I already saw such request in Feature Request forum. Not something supported by BTSync immediately - but nice idea. For the checkbox - there are a plenty of advanced settings which we don't want to have immediately accessible to not to confuse users.

@mbi The change log I publish on forum is always comparing to previous published version. I.e. 1.3.94 topic has only changes comparing to 1.3.93. The auto-updater change log contains changes comparing to previous version published on auto-update.

@ckp BTSync isn't doing any throttling or intended delays. It runs a thread which is doing indexing - and usually bottleneck is a HDD, not a CPU. BTW, disk defragmentation might help to speed up indexing.

@groomedmonkey The fact that files were moved to .SyncArchive indicates that one of peers decided they were deleted by user / some other app. Could you try to find which computer in your swarm did that? (this would be the only PC which won't have removed files in .SyncArchive). Do you have the full logs from that computer? Also, do you remember any significant even that might trigger deletion? (some app running and utilizing files, BTSync upgrade, etc) As for the history log - the Feature Requests forum already has the request to make logs persistent between app restarts.

@Insec, I'm not familiar with Dropbox source codes so I can't say which technology and which algorithms do they use to determine if file change is complete. For BTSync it takes 10-20 seconds to start sync. The team is working constantly to improve BTSync, so it might get better in future.

@ralphioooo, It transfers more if we are talking about smaller files (below ~5Megs). I advise changing "low_disk_priority" to "false" in advanced preferences and see if issue persists.

@Raccoon 1. Please see forum topic: http://forum.bittorrent.com/topic/29304-rules-for-valid-secret/ 2. "best" from which point of view? Cryptographical strength? Calculation speed? Something else? 3. Yes, there is one major drawback: the strength of the secret generated in that way. The hash generated in such way becomes very vulnerable to brute force attack with vocabulary.

@A3414896 I'm working to find out a precise answer for you. Will contact you soon.

@Lobo204, The steps are pretty much common with all Linux environments. The command output shows you need to use x64 binary (however, x86 should also work). 1. Connect to your NAS via SSH. 2. Stop btsync (kill <btsync_process_id> would do the job) 3. download BTSync binary ("wget http://download-lb.utorrent.com/endpoint/btsync/os/linux-x64/track/stable") 4. unpack binary (tar -zxf <archive_name>) 5. use "find / -name btsync" command to locate btsync binary 6. replace if with freshly downloaded. 7. start BTSync.

@aid85 1) There is no such functionality on Android client. It was already mentioned on Feature Request forum, so no need to add it one more time. 2) Could you please elaborate your question? A step-by-step description would be perfect. 3) Would be nice if you mention it on Feature Request forum 4) Thanks, glad to hear that it looks good to go. For now whole team is working hard to make project even better and more reliable!

@johatfie Just another idea - the bottleneck might be your HDD. If you've got 2Gb LAN connection, it is roughly around 240 Mb/s bandwidth, which is nearly 2.5 times faster than your HDD allows. @2disbetter Yes, it might happen.