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. Synology DS214+ working with community package.
  5. 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 before shutting down. Please don't talk about "several seconds" for "very large folders". I can demonstrate the opposite at will. I dropped BTSync from my environment (2x Windows 8.1, 2x i386, 4x APK, 1x x64) a month ago and I'm back to usual start experience - seconds to start my Windows 8.1 PCs. As I wrote already here, during BTSync start (at least on my Windows PCs) came a point where everythings running in parallel (loading the list of shared folders, re-indexing the first shared folders and transfering the first changes to/from the first shared folders). On my i386 machines I could see trillions of I/O on my files per day. For small environments BTSync is ok, currently. For my 16 shared folders, 200GB size and around 80,000 files it was a ressource killer. I will wait for the next Beta later this year.
  6. Just a question: Is it 8 packets per second per share or is it independant from the number of shares? Thanks
  7. 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 8.1 64bit, QuadCore, 8GB RAM1x x64 Linux vServer, 16GB RAM2x i386 Linux 4GB RAM Minimal System (unRAID)4x APK (3 different devices, 3 different Android versions) Let me say first that I was using BTSync in a real environment with lots of shares, lots of folders and lots of files. It's way below the 1,000,000 files that are written in the unofficial doc. IMHO this is only a theoretical limit because I do hit limits with 203 GB, 21 shared folders, 13,000 folders, 110,000 files and 11 devices). This is a typical company environment that BTSync will address in the future too - I will wait for that. 1.) BTSync crashes my WLAN repeaters (AVM) This was reported so many times here. Most of the time the manufacturer should have a bad implementation. So many? The hint was "[...] switch off UPNP [...]". Whenever I start BTSync on my Android Devices, after an hours or so my WLAN repeater is dead. I have to remove it, wait 60 seconds and put it back. When that happened the first time I thought it would be a problem with my old WLAN Repeater and bought a new one. The problem still does exist with the new one. UPNP is off, LAN TCP is true, LAN encrypt is true - no luck. 2.) Hardware ressources (RAM and drives) This is really the reason why I dropped BTSync yesterday. In a previous post of mine "These Shares Need 8Gb Ram On Windows 8.1" I wrote about my experience with two Windows PCs that won't work for my shares if they don't have at least 8GB RAM installed. They crash with a HANDLE error, blue screen, Windows dump, automatically reboot - in an endless loop. Within the last week I did experience another bad behaviour of BTSync. Two dead harddrives within one week in my two i386 servers made me nervous. Both servers are used in an office. Both have 15 drives each and BTSync is bound to disk1 in both arrays. After investigating I saw at least 10 million file operations per day. Per day! For 110,000 files! For read-only shares! We use customer drives, no special 24/7 drives. Seagate ST3000DM001 is the type, but both had different model numbers - one from China, one from Thailand. Yes, I could increase the re-index time, but what sould I use? So I always use standard values. An hour before I did remove BTSync I did a last check with one of my Windows PCs. I could see that with my list of folders three operations are running in parallel during BTSync start: 1.) Create the list (see attachment for my list of shares)2.) While the list is being created the first shares start to re-index3.) While re-index is going on, the first data is transfered from and to the machine. Everything in parallel. The harddrive lights are burning for 15-30 minutes. It's just a guess, but I think that's one possible reason for the handle and memory problems I saw on several machines. So good luck, I'll wait for the enterprise version. I hope you'll GA only after some real world tests with 100th of shared folders and 100,000s of files - companies do have that usually ;-) For me BTSync is a wonderful idea and could be the next step in cloud storage evolution. So I will come back, definetely, but not within these beta time frames. Thanks for listening
  8. 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 same share. The first things that happens before the crash is that BTSync reports something like "can't find folder", then Windows goes black and asks to send a crash report to Microsoft. After that bad experience I disabled autostart of BTSync and did start Windows again --> without BTSync Windows 8.1 worked again. In a next step I did upgrade both machines to 8GB --> now both, Windows and BTSync, do work again. In a previous thread I wrote that I had to increase a vServer from 2GB RAM, over 4GB RAM and now finally to 16GB RAM to get BTSync up and running. Here dCacheSize was the limit. The attached screenshot shows my current shares. This environment (143GB and 72,000 files total) is to much for BTSync on 4GB. I heard some rumours here in this board that the next release might need not that much memory and system resources. IMHO this is needed, really.
  9. 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-index (during boot or automatically during application run) beats all my systems. This is beta software - so I'm quiet comfortable with it. But for general availability this needs to be fixed.
  10. 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 of free space * The Devices tab on the Windows App shows the differences since days (7.8MB to go) * I did reboot source and target several times in the meantime I do see that behaviour with all my four Android Devices (three different Android releases, three different models). In fact, after some weeks of usage, not one single share (out of 16) shows the "synchronised on xx.xx.xxxx" text. All devices report incompleted shares. I went thru this several times now. Did sync all devices manually with TotalCommander. Did re-install the APK, added the shares and did wait until everything showd 100%sync. Then, after some days of work, the first shares report uncompleted operation. After some weeks all shares are out of sync. It's only the Android APK, not my i386, x64 and Windows 8.1 machines. Thanks.
  11. 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 to more connections/traffic. No, just one single pre-filled share and just one remote peer, and boom. It's a 2GB/4GB, 2 vCore, 200GB vServer and that's not enough. Whow. I did cancel that experiment and did delete my vServer account. It's useless for me.
  12. 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.
  13. Please don't hijack my thread. Please open another thread for your question.
  14. Looks like a content of a .SyncArchive folder. Are you syncing a HTTP access.log?
  15. 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: