hawibtsync

Members
  • Content Count

    60
  • Joined

  • Last visited

  • Days Won

    1

About hawibtsync

  • Rank
    Advanced Member
  1. Thanks. My Android devices did update to the latest release automatically. Will uninstall everywhere and wait for an update to my central, and always-on, NAS device Synology DS214+. Regards
  2. In my environment with several Windows, Linux, Synology NAS and Android devices I'm using BTSync. Some of the devices are several BTSync releases behind. For example I don't get an update for the Synology DS214+. The community package I did install with the Sysnology Package Manager is still on 1.2.82. Is this save or should I drop BTSyanc on all devices until all are on the same and latest release? Thanks.
  3. It seems that since the latest update from 03/25/2014 I can't close the app any longer. It's service and its notification icon reappears always. I need to force close the app from within the Android settings. The settings within the BTSync app are set to don't allow automatic start during boot. I can reproduce that at will on our four Android devices (1x Galaxy Nexus on 4.3, 2x Pipo M9pro on 4.2.2, 1x Magic Cube U9GT2 on 4.2). Thanks.
  4. Sorry for buttin' in. I had large folders in BTSync and the startup on my two Windows 8.1 PC slowed down to the point that my 4GB RAM Quad-Core crashed with "out of handles" errors. 15 minutes re-index at nearly 100% disk activity was the minimum for my environment. I did create two posts here in the forum describing the count of shared folders, files, directories and file sizes along with some screenshots. The 4GB Quad-Core machine couldn't handle BTSync at the end. The 8GB Quad-Core needed the 15 minutes until BTSync had finished its startup - and I usually waited for BTSync to complete be
  5. Just a question: Is it 8 packets per second per share or is it independant from the number of shares? Thanks
  6. In a post 1 or 2 days ago I've read that a new beta release will not arrive until March or so. As I'm having lots of trouble with my BTSync environment this is bad news and I started dropping BTSync from my machines. I know this software is beta, but I won't test this beta release for another 1-2 months - I do have lots of serious problems. Let me explain my descision. Here are the BTSync releases I was using: 4.150.213 BTSync-1.2.14.apk1.648.488 BTSync-1.2.82.exe2.044.500 btsync_i386-1.2.82.tar.gz2.218.854 btsync_x64-1.2.82.tar.gz These are the machines BTSync is running on: 2x Windows
  7. Environment: 4.150.213 BTSync-1.2.14.apk1.648.488 BTSync-1.2.82.exe2.044.500 btsync_i386-1.2.82.tar.gz2.218.854 btsync_x64-1.2.82.tar.gz 2* Windows 8.1 64bit, QuadCore, 4GB RAM 1* x64 Linux vServer, 16GB RAM 2* i386 Linux 4GB RAM Minimal System (unRAID) 4x APK Today I had to exclude 2 Windows 8.1 machines from my sync environment because they started to crash during bootup. BTSync usually starts automatically after Windows. The first thing BTSync does when it starts is to re-index. This re-index crashes both Windows 8.1 machines now when it comes to the last shares. It's not always the sa
  8. Yes. I can confirm that for the current 1.2.82 releases. In the last couple of days I did lots of tests with my 16 shares (132GB, 72,000 files): 2GB RAM/200GB HDD vServer Linux - crashed when adding the last two shares (nothing else running on that machine), dCacheSize/kMemSize 4GB RAM/400GB HDD vServer Linux - had occupied system resources at 99% 16GB RAM/800GB HDD vServer Linux - is running without problems 4GB RAM/800GB HDD Windows 8.1 - crashes during re-index (boot of machine) with an HANDLE LOW error 8GB RAM/800GB HDD Winows 8.1 - (that same machine) works without any problems Re-i
  9. Please have a look at the attached screenshot. I do see these two pending downloads since days. In the meantime these files did change on the source computer two times - but they are not updated on the target. The grey line shows that the App knows to download - but it doesn't. To answer your questions: * Latest APK * Readonly share * These files did exist on the target. After some days I did delete them but they are still not synced. * These files are not locked on both sides * No *sync* or *Sync* files on both sides * No matching SyncIgnore patterns * Both, source and target, have lots o
  10. It's Virtuozzo running on this providers vServer systems. Yesterday I did one last test before definetely canceling my order: I did re-install BTSync - this time I used the i386 release. I completely filled the biggest share (18,000 files) on the vServer and did add just this shares secret. I did shutdown BTSync on all but one machine - a Windows 8.1 PC. After some minutes the vServer crashed again. I mean, the data was already there. The only requirement for BTSync was to re-index and check the values with one single peer. My idea was that x64 needs more ressources, that more peers lead t
  11. Not the same. Your HDD keeps filling because you sync the HTTP logs of a web server and produce duplicates in SyncArchive every few seconds - perhaps there's a bug or misconfiguration around file versioning. I would never, ever sync a log or tmp folder - but that's my personal opinion.
  12. Please don't hijack my thread. Please open another thread for your question.
  13. Looks like a content of a .SyncArchive folder. Are you syncing a HTTP access.log?
  14. Here's the last thing I could gather before the vServer died again. cat /proc/user_beancounters shows a lot of fails. . Attached is a screenshot of my shares (in Windows) and the cat /proc/user_beancounters just in the second before the system died: