• Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by hawibtsync

  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 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.
  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 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
  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 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.
  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-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.
  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 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.
  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 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.
  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:
  15. Yep, exactly. When the problems started - and there was plenty of empty HDD space left at that time - df/ls/top/etc stopped working. When leaving the SSH session a new SSH session was refused. Plesk returned an 500 Internal error. The BTSync Web-GUI came up with an empty list. BTSync itself was holding the existing connections to the remote peers but did not transfer anything. vServer needed re-boot at that time. One of my two 8.1 Windows machines (8GB RAM, Quad-Core, 700GB free) yesterday evening started to receive blue screens when BTSync was re-indexing locally. The message - disappearing very fast - showed something with "*HANDLE*"... I guess my environment started to hit against BTSyncs limits. I've read about millions of files here - I can't believe that any longer. As I wrote in my first post: 16 shares, 9 peers, 130GB (total), 72,000 files (total), 42GB biggest share, 18,000 files largest share. BTW, I'm wondering how Backupsy handles this - their machines have 512MB ... *EDIT*: Just in case - here are the releases I'm 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
  16. In my own LAN with 2x i386, 4x APK and 2x Windows 8.1 BTSync works fairly ok. Yesterday I did start a new experience. I did order a vServer with 2GB guaranteed/4GB dynamic RAM, 200GB harddrive, 2 vCores. Without any additional configuration I copied the current x64 version of BTSync to that machine (Debian 6) and did start to sync. I did use encrypted shares (API) to test the results. After some time the vServer did freeze. Within 36 hours the vServer crashed three times, once with the host system coming down. After some talk with the technical staff I was told that btsync did use DCachesize to the vServers limit. Lots of failcnts did lead to the vServer crashes. The last employee told me "[...] perhaps a vServer is no good idea for BTSync [...]". As I said, I'm using un-encrypted shares on my two i386 machines (Slackware, 4GB each) without any problems. I'm holding 16 shares, with the biggest size share holding 40GB and the max count of files in one share is 18,000. Any ideas? Any hints are highly appreciated. Will the x64 use much more ressources than i386? Thanks in advance. *EDIT*: What I forgot to say: Not all files/shares were copied when the problems started. There were 6 peers connected - if that matters.
  17. I'm using BTSync for some time now with 2x Windows 8.1, 2x Linux i386 and 4x Android - all on latest releases. Today I've setup a new Android device and did add all my existing shared folders in r/o mode. Now during the copy I do receive lots of errors "ReadFromDisk: Unzulässiger Zugriff auf einen Speicherbereich" - in fact every 5-10 minutes one of the files fails. The source of the data is a Windows 8.1 machine, the target an Android PiPo M9Pro. What does this error mean. Is it really a read error on the source machine or a read error on the target machine (a verify or something like that)? I did enter all shares at once (20, or so) and did start the automatic sync for all folders at once too. Could it be a race condition because of massive parallel access? Thanks in advance.
  18. Please read what Dropbox writes: "[...] but one will appear as a copy of the original file and appended with case conflict." It was always easy to find any problems with Dropbox. They append a hint to the files/folders that produce problems. With Dropbox you can always search for any problems that happened during sync. BTSync gives no hint at all. This is why I wrote "silently" - that's the real problem...
  19. You don't get it. Users of Bittorrent Sync will loose data if they ever rename a file from "A very important file.xls" to "A very Important file.xls". They will lose it silently. No warning, no error, no popup. In, say, 2 month you will notice that this file is gone for all partners, on all attached devices, on all platforms - forever. And SyncArchive is empty at this date... BTW, the character limitations as mentioned are well known by the average user.
  20. Windows limitation? Who cares? The product needs to handle this. The main audience of BTSync _IS_ mixed environment where nobody knows what Operating System partners will use. So I would suggest a HUGE warning in the documentation before going GA. Something like "When using Bittorrent Sync in mixed environment don't rename files - uppercase to lowercase or vice versa - you will loose your data.". Leaving it as is will generate lots of problems - guaranteed ... BTW, I'm no BTSync developer but wouldn't it be easy to find out that somebody tries to rename a file (case change) on the Windows platform? A proper warning could pop up then. It's just a suggestion...
  21. I had some problems in the past so I tried to reproduce it. Here we go: Windows 8.1 with 1.1.82 Linux i386 with 1.1.82 Android with 1.1.33 Please have a look at the screenshot. * I searched on the Linux box (Tower) for lower cases in front of a word. * I changed that on the Windows PC for 6 files. For example: "Die Liebe in Zeiten Der Cholera.epub" to "Die Liebe In Zeiten Der Cholera.epub". * --> All six files were added (not renamed). IMHO this is the first error. * On the Linux i386 box I ended up with two files for all 6 examples ("Die Liebe in Zeiten Der Cholera.epub" and "Die Liebe In Zeiten Der Cholera.epub") * On the Linux box I did delete the files with small capital. The other file was left on the device. * --> Now all six files were deleted on the WIndows boxes (but the one with the big capital, not the ones I did delete on the Linux box). IMHO, next error. * --> As a result they were deleted on all other devices. The result: Renaming a file from uppercase to lowercase or vice versa destroys files! Regards
  22. Ok, I see. What happens on a readonly secret if the source adds new files? E.g.: * One device has a big library. Another device receives readonly secret. This second device starts to remove files after usage without affecting the source. Now the source adds new files. What happens? I did ask that in another thread but didn't receive an answer. Is this way to go for small Andoid devices that want to keep up with new files but want to delete files as well?
  23. For me it sounds as if the iOS release is working perfect and the Android release is buggy. I don't expect software to do something "automatically" if I switch "automatic handling" to off.
  24. What does automatic sync mean then? I switched it off and the Android device did delete files "automatically" on my other platforms ;-)