Shaav

Members
  • Content Count

    21
  • Joined

  • Last visited

Everything posted by Shaav

  1. I have been struggling for a couple of months now trying to get 4 QNAP NAS drives syncing about 2TB of data, all of which had been pre-loaded. Indexing has been a nightmare and never seemed to move forward. For weeks and weeks. Finally, I found that if I stopped btsync on all but one NAS at a time, it would successfully sync all 2TB in about 12hrs. Note, btsync had to be *stopped* completely (i.e. I would ssh in and run ./btsync.sh stop --- not just paused in the UI. Pausing seems to stop the transfer of files (?) but not the back-and-forth communication about the files and somehow, it
  2. @adam1v Not as far as I am aware... but I'm not necessarily in the the loop either. Just didn't want to leave you completely hanging since there have been no other replies...
  3. +1 Would also be nice if there were two levels --- a default global for all shares and then a share-level IgnoreList that would sync across all devices using the share.
  4. @GreatMarko Thansk for the link; will do that.
  5. @RomanZ It is entirely possible that I mistakenly put it there in the past; I just don't remember. Also, because the documentation isn't entirely clear on that point (something that could maybe be addressed?), I possibly put it in both locations "just to be safe". However, increasing the number of devices/shares certainly makes that less feasible quickly. It would be nice if there were a global IgnoreList and a local IgnoreList BTW... But I realize that's a very linuxy kind of thing to do. It would also be nice if the IgnoreList become a propogated property of the share so that if you edit
  6. @Moe Frankly I'm having enough of a miserable time experimenting around trying to understand the behaviour of this software --- I thought *maybe* it was a simple enough question to get straight, conclusive answer instead of trying to reverse engineer it from observation.
  7. Just want to quickly clarify something... The documentation says the IgnoreList goes in the hidden .sync file; my interpretation is that it means the /share_folder/.sync folder rather than the /run_path/.sync folder. But I have IgnoreLists in both locations and I'm not sure if that's by design, because of upgrades where the location changed, or if it was something that I just mistakenly did at some point in the past. What I kind of *hope* is that you can put a global IgnoreList in /run_path/.sync that applies to *all* folders and then a share-specific IgnoreList in /share_folder/.sync and
  8. I realize this is an issue that people bring up here a lot; I haven't really seen much by way of solutions---seems like a lot of them abandon btsync before it gets resolved. I'm hoping that I have more detail to offer about what happens than others... Situation: 4 QNAP NAS drives syncing about 2.3TB of data; ~700K files. All 4 drives are using the latest 2 version. All the drives currently have ~99% identical content; just differences that have occurred from their use since the problems began. 2 of the drives have been functioning perfectly for about 8 months; the problem came when we tried
  9. @RomanZ I was eventually able to verify that they could talk to each other, FYI. There's just other stuff going on. Topics for other threads.
  10. @RomanZ Will look into trying that. Unfortunately, these are all QNAP NASs that don't have netcat on them. Will need to figure out getting in on there first...
  11. Specifically here, I think it would be a lot more functional if rather than renaming the files the way you do now, is always have the most recent version keep the same file name and then rename the versions such that the highest number is always the oldest. I know that means renaming more files on a regular basis, but it would become much easier to, say, write a script to deal with problems like mine.
  12. @RomanZ Yeah... sadly in the situation I'm in, all the files from one peer were deleted which propogated... I rsynced the files back (including all the .n archives cause... hard to separate them out) and neglected to use -a so all the modification times got updated. So no help there. Thanks for the info though.
  13. @Romanz That is what I mean I did when I said "EVEN when I provide explicit VPN IPs and ports for the peers". Does not work.
  14. When files are changed and archived, .sync/Archive/path/ has multiple versions of the file named: file.n.ext and it appears that the highest "n" is the most recent file. Consider this scenario where the default retention period of 30 days is in effect and the same file (test.txt) is edited on a weekly basis: .syncArchive/path: 2015-06-12 test.4.txt 2015-06-05 test.3.txt 2015-05-29 test.2.txt 2015-05-22 test.1.txt 2015-05-15 test.txt by the time 2015-06-19 rolls around, the 2015-05-15 test.txt will be deleted. What will the name of the new archived file? test.txt? or test.5.txt?
  15. Thanks @RomanZ --- this is kind of an unusual case and I'm using VPN because I don't have direct access to the networks in question (except 1 --- not the one I'm particularly interested in. ). So I don't have any idea what the routers or their configurations are like for 3/4 devices that are syncing. I've been experimenting quite a bit and the peers do not seem to find each other on the VPN. I.e. if I turn off relays/tracking/DHT and just leave searching the LAN, they do not find each other. But more surprising, EVEN when I provide explicit VPN IPs and ports for the peers, they won't find e
  16. I am using BTSync with devices that connect to each other with a VPN. So they each have an IP address on the local LAN (where they are alone) and also an IP on the VPN. When I check "Search LAN" will it search both? Or just the local LAN? Obviously, my preference would be for BTSync to work over the VPN. When it is "searching", is each client sending a broadcast and waiting for a response? Or just listening for a broadcast?
  17. Facing a similar issue... what did you eventually do? Just wait until it was finished indexing?
  18. Here's the situation: I have had two QNAP NAS ("Q1" & "Q2") drives syncing happily for 7 months using 1.4; just over 2TB of data (about 650K files). This last week I wanted to add two more QNAPs to the mix ("Q3" and "Q4"). They have 2.0 installed. (For the time being, I have reasons for not wanting to upgrade Q1 and Q2 although will if necessary). I pre-copied over all of the data from Q1 to Q3 and Q4 which are all on the same LAN. Q2 is still in the swarm but over the internet. I set up the syncing; everything seemed to be OK. However the indexing was taking *forever* --- 3 days and
  19. It's been a bit of a nightmare, but I finally got this sorted on my two QNAP TS-421 Two step process: 1. I had to ssh in and edit the startup script: /etc/init.d/btsync.sh (which just links to /share/MD0_DATA/.qpkg/BitTorrentSync/btsync.sh and add the line: umask 002 somewhere near the beginning. I added it just before the "case". Note: it seems extremely likely that if you update the package you will need to redo this step! 2. Make sure that all your existing files and directories have sufficient privileges and the correct ownership. From the top level share (/share/MD0_DATA/<
  20. Also having this problem on a pair of identical QNAP T-421 both running 1.4.76. Oddly enough, it only ever happens on one of them; not sure if that's just because of the direction of the syncing it's trying to do or what... Everytime it fails, btsync crashes (process dies) and it's always with this set of log entries (although the file can change): [20141014 00:51:20.989] TorrentFile: 0x7460bea0 created [20141014 00:51:21.041] FC[C042]: LoadTorrent: wrong number of pieces for file /Path/Document.pdf without metadata, resetting it [20141014 00:51:21.041] [OnNotifyFileChange] "/Path/Document.