bmattis

Members
  • Posts

    9
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by bmattis

  1. Now the QNAP support has done some analysis and it seems like it's a memory thing making the unit unresponsively super-slow. They say that: So, the NAS can simply not behave robustly when it runs out of memory -- which the user will probably not be able to know beforehand that it does. One way I found to minimize the problem is to disable the zip file scanning in the antivirus settings, or at least to greatly reduce the size of zip files allowed for scanning. When changing that setting from 200 MB to 10 MB, the antivirus scan actually finished in a couple of hours, and the NAS was responsive (albeit not fully stable) meanwhile. But all in all, it's about bad out-of-memory handling, so I urge all developers of Sync apps and other apps to keep their memory at the minimum instead of lazily relying on the users getting bigger and bigger systems all the time!
  2. No logs or dumps, since it doesn't complete the scan. No interesting dumps when Sync is disabled and the scan completes. I have filed a ticket at QNAP a week ago, and they are remotely checking my NAS at the moment. We'll see what they say. Anyway I wanted to inform all parties that are somehow related to the problem.
  3. Doesn't seem very similar. My *NAS* stops responding, not my Sync app. And I *have* antivirus enabled. :-)
  4. Yes, the built-in antivirus in the QNAP NAS UI. If the Sync app is activated, the antivirus doesn't have a chance to finish and give any report. If Sync is deactivated, the antivirus doesn't find any problems, so no interesting logs or reports. The scan job has the following settings: Scan 2 specific folders (one of which is Sync'ed), weekly, quick scan, scan compressed file content, deep scan for document files, only report the virus. The virus definitions update daily. My QNAP NAS is a TS-131.
  5. Since some months back I've encountered my QNAP NAS totally unresponsive once a week, needing a reboot to be usable again. With help from QNAP's support, I've narrowed the problem down to the Sync app in combination with the antivirus scan provided by QNAP: - I have the antivirus scan scheduled to run once every week. One of the folders in the scan job is synced by the Bittorrent Sync app on the NAS. - After some hour of antivirus scanning, before the antivirus reports a finished scanning, the NAS becomes impossible to reach on the network. It happens every time, and the NAS has to be rebooted. No logs show any direct clues to what happened. - If I disable the Sync app, though, the antivirus scanning jobs always finish without a fault! - If I re-enable the Sync app, the NAS hangs again at every scan job. I don't know if QNAP or Sync (or both) is to blame for this error, but it makes Sync much less useful and reliable. Worth noting is that this error started appearing some 6 or 12 months ago, so it was introduced in some software update from Sync or QNAP, probably during early 2016 or so. I have regularly updated the NAS and Sync several times the last year. It should be mentioned though that I still run one of the last versions of Bittorrent Sync before the rebranding to Resilio, so I haven't tried out the last version and due to various bad experiences I am not currently planning on installing it. This is more of a bug report than a cry for help.
  6. Sounds great! :-) Another aspect that I forgot to mention is the need of an indication of agreeing or disagreeing clients in regard to the IgnoreLists. As of now, you never know for sure if the IgnoreList is working or not since there is no indication that both sides have matching text files.
  7. The fabulous Bittorrent team would really need to make a clear and user-friendly GUI for file & folder selection. The current old-school .SyncIgnore text file solution is surely preferred by some computer boffins, but it is way too cryptic for the broad range of users, and - as this discussion thread shows - even the relatively nerdy of us have a hard time actually getting it right (or even understanding the exact results of what we try). In a sync/backup tool, every uncertainty is potentially dangerous. A new GUI-based selection could still be combined with the old text file solution, rendering a new text file when setting has been changed in the GUI (and vice versa). This would also make it much clearer what the lines in the text file actually mean.
  8. Not working for me either. It keeps on syncing stuff in the AppData directory. This is on a WinXP PC which backs up a read-only sync from a WinVista PC. Btw, do the .syncignore *files* need to be identical, or is it the parsed text data that needs to be identical? In other words, does a linebreak or a whitespace in one of the files break the validity? And is there a chance to see if two folders have mismatching .syncignore files, via a warning message or log entry or something? I guess every user would always want to get alerted about this immediately.
  9. Hi, first of all I want to say that I'm really happy to have found BitTorrent Sync. Wonderful stuff! Now I'm trying to set it up in the best way, and my primary question is about re-indexing. As a little server I have a netbook running BTsync, and a NAS storing all my synced files. The NAS is working almost all the time, since BTsync says "indexing...". I assume this takes much longer time on a NAS than it would on a local drive. (I know that I can change the rescan interval, but it still takes a lot of time when the indexing is running.) I find the eternal chewing on the NAS both annoying and worrying. So, here come two alternatives: - If I would use a locally connected USB drive instead of the NAS, would the indexing be much less of an annoyance? Would BTsync even know about the file changes without having to rescan the files? (Dropbox seems to know it. And, as a comparison, the AeroFS guys say that they don't support NAS syncing since the system then doesn't get all the file-change information.) - If I would use a NAS running BTsync instead, like the WD MyBook Live, would it have to re-index my files as much? Or would it work more silently and well-behaving? Speaking of rescan intervals and file-change information in the system - are both always used by BTsync? To put it in another way: if I increase the rescan interval, will BTsync always still react to changes done between rescannings... or does it depend on where the files are stored? Explanations & recommendations very welcome!