• Content Count

  • Joined

  • Last visited

Everything posted by Timbo

  1. The sync.log contains over 110,000 lines of the following in just the last 2 hours: SyncPeer::RemoveFromDownloading SP:[812B] index = 659 Needs more error detection and alterting. There's no errors listed on History page. Turns out, the error was happening on the other peer. Had to add group write permissions for it to ADD a closed caption file that was added on my local side (normally, the files are added by remote peer and deleted on local peer). Not sure why I couldn't write a new file but could delete them all this time. *shrug* I wouldn't have made my local side appear to be properly in sync when the other side was in error and showing the problem. It's a headless linux box, I wouldn't normally be looking there for errors.
  2. Do you have any bugs filed already for the taskbar sync icon in continuous spin despite no active transfers? Not a big issue, just annoying to see it constantly spinning, looking into what is being transferred, and then not seeing anything being transferred. There have been bugs in the past that was just trying over and over and over to transfer the same files that was using about 300Kbps of bandwidth (for over a month continuously) that would have made a really expensive ISP bill if it went over my Internet connection, so I'm sensitive to seeing Sync claim transfers when I'm not expecting it. Or leftover stale numbers displayed under Progress column when no active transfer is happening? It's very easy to reproduce when downloading a large file that gets sync'd in partial chunks, but I've also seen it happen regularly outside of that.
  3. Well, disabling IPv6 for the OS is not recommended, generally. But there is no route to the Internet, so why the app keeps trying is just bad behaviour and waste of resources. Also, you're aware that IPv4 and IPv6 use the same interface, so how would specifying the interface to bind to will help? I checked it out before posting. I specifically don't want to do this, as I have multiple NIC's in these machines. I believe I will go ahead and disable IPv6 on my WHS 2011 box and see if there is any fallout. But this should have been a setting when IPv6 support was being added, I was surprised when advanced options didn't have it.
  4. When looking in the logs, I noticed lots of messages about lack of connection to an IPv6 tracker. Since my ISP doesn't support IPv6, I was assuming that only local LAN peers would use IPv6 and all Internet connections would be IPv4. Right now, it just looks like a lot of wasted time trying to talk to this tracker that it will never be able to talk to. I don't see any option in the Advanced properties. Is there a way to disable IPv6? Thanks
  5. Error 3 is for file not found, as per that useful link you provided. Which is the case. It keeps looking for path\.sync\Streams for each of my syncs, and it doesn't exist. There is a StreamsList, with timestamps of 2014 and 2015 in the ones I checked. Perhaps its leftover code from earlier btsync...
  6. Unlocker reports no handles on the files in question. There's no problems with permissions. I can delete them from Explorer on the same or remote machine just fine. It just doesn't work with uTorrent anymore after BT sync design was changed. When a torrent was completed and no longer being shared, it used to be able to be deleted no problem. After some design change in Sync, you had to completely remove the files from uTorrent (remove data+.torrent). I thought it was fixed after 3-4 versions, but doesn't appear so. It seemed there was a way for the GUI to reflect that a file was locked and to keep retrying, but not in this case. No indication of failing to delete hundreds of files over months. That's a design flaw if the user isn't made aware of problems and needs to take action. Having to go through these logs should be in extreme corner case debugging, not intentional by design. The log has dozens of entries for files that ALREADY exist with "- error creating on disk". These are also files that should have been deleted long ago. That makes zero sense. It seems the logic is bad in some cases. My best guess on the bug, is that if it got an "Access is denied" error, its latching it and never retesting it like it should for when a file is locked. You can probably add this Access is denied check to the same code that helped fix the File Locked problem. Edit: Correction. These files had the attribute "read-only" applied for some reason. It was only on one side and not the other (?!). Shouldn't read-only attributes also be sync'd to the remote side? If not, perhaps that was why the other side could delete things fine. I have no idea why these files are marked read-only. It appears uTorrent caused this. Googling for uTorrent and read-only lead me to an advanced setting that was mysteriously changed to True: bt.read_only_on_complete However, not all files are being set to read-only and the randomness of this is why it took so long to figure out. Anyways, I worked around by setting the uTorrent setting above to false, and deleting the files in Explorer (no prompting or hinting of read-only issue), or from command line, changing it to "del /f filename" to mass delete them from command line. So I would say the corrective action is to either flag a read-only file in the GUI for the user to deal with it manually, or just add "/f" to your del command to actually remove the file as the user intended.
  7. I just noticed this today that I'm having a similar issue, except between two Windows machines. Looking at the date, it started happening with 2.5.10. Adding files works in both directions near instantly. Deleting on Win10 doesn't remove from WHS 2011, but deleting on WHS 2011 is near instant delete on the Win10 box. The sync.log is filled with unable to move "file" to trash, error 5. And some error 3's. I hate when debug is useless without a decoder ring. I've tried restarting Resilio and rebooting. No alerts or issues showing in the GUI. Not looking forward to spending an hour tracking down and deleting near 200 files over 2.5 months because Sync has really poor error handling and alerting. Sync is really nice when it works, and a real PITA when it forks up, which seems to be a regular occurrence
  8. Encrypting and decrypting will definitely add overhead and decrease throughput. How much depends on the size of the files, the number of files, and the CPU's of each side. There is very little CPU used in network transfers with the NIC doing a lot of the offloading. With encryption the CPU has to handle each packet a lot more than once or twice and uses up both RAM and CPU. I would expect you to get higher speeds between two XEON PC's than a NAS and XEON PC. Unless you have a fairly recent $1K NAS box.
  9. How long after a release do you push linux updates to your rpm and deb based repositories? The rpm one is still at 2.5.4 I believe. Perhaps it might be too early to say, but 2.5.7 > 2.5.x by a long shot.
  10. I had Sync on a VPS with 512MB of RAM and syncing about a half a dozen files of about 2GB average in size. Sync crashed often. When the VPS was increased to 1GB of RAM, the crashes stopped. When I was investigating crashes, rlsync was using more than 350MB of RAM. I was not expecting this, considering a good chunk of NAS' only have 512MB of RAM. Developers need to design specifically for embedded devices, they don't have the resources PC's have.
  11. Helen, Do you test with any high speed interfaces other than 1GB ethernet? Even with 1GB ethernet directly connected between peers, what would you expect for throughput? On older 2.x versions, IIRC, I was typically getting transfers in the 400-800Mbps range. When I change to 10GBe, I would peak around 1.1-1.2Gbps. Ever since being on 2.4.x+, I don't think I've ever seen higher 400Mbps. I see a lot of really small speeds, like 10Kbps on my phones while on the wifi network my local PC's are on. The other day, on two hosts with 1G and 10GB connection between them, I also only saw 10Mbps even after restarting both sides multiple times. This was already using predefined hosts, disabled relay, disable low priority, disable lan encryption, etc. For these two hosts, the shares are on RAID10 with read speeds of 250MB+/s. I think I will need to make a test setup and get you some support logs, because a number of the issues I've encountered are still present more than 6 months later and sounds like you need more help identifying these issues. If the logs could filter out certain shares and be limited to certain problematic shares, I would have done that ages ago.
  12. Helen, You don't see this with simple pulling of ethernet cable, waiting a minute or so and plugging back in? This is as simple as reproducing the issue as it is. I believe I have a bad 10Gbe NIC that would lose communication a couple of times a week until I pulled and reinserted the cable into the switch to restore communications. Sync just would not see other peers unless app was restarted.
  13. Also, it looks like 2.3.8 finally uninstalled on its own. It took close to but less than 34 minutes (when I noticed). That's longer than the longest Microsoft Office uninstall including reboots!
  14. I just noticed the Clock icon after upgrading QNAP to 2.5.7. I looked at this tab on the Win10 machine and now I can see the path for folder.jpg and AlbumArtSmall.jpg because the entries for these go back further than 12 hours, and when I look on HomeServer, it goes back past August 12th!!! However you're updating the file, its not correct or else it wouldn't be syncing the same file over and over and over and over...
  15. Ever since going to the 2.4.x+ series, I've had nothing but issues with non-stop syncing. I started off with a 25GB music folder being synced between a QNAP NAS, Windows 10 and Windows Home Server. I would copy the music to an SD card and put it in my phone. I did that again with another phone. So I'd have 25GB of music that was exactly the same in 4 places, with the exception of maybe a dozen mp3's that would be on a device only. When I added both these phones to the Sync that was between Win10 and Windows Home Server, the Sync on Android kept crashing over and over and needing to be closed and reopened (my phone has 3GB of RAM. Based on this and your memory footprint, you're developers are not really optimizing for embedded devices.. but anyways). I also had to disable the default "selective sync" in order for the syncing process to say it was finished, otherwise it said like 5GB out of 24.9GB for over a week. There was non-stop syncing for days and days. The progress was on 98-99% and say "a few seconds" the entire time. The queue of files to be transferred only ever increased. There would be 10-20KBps of traffic non-stop when phone was on same local network as my Windows 10 and Windows HomeServer. Because I can click on the Peers Online link and see how many files were in the queue, I could see that they were all "Folder.jpg" and "AlbumArtSmall.jpg". I guess the phones were pulling down album art and having problems syncing those to the other devices. The queues would never get less unless I did a mass deletion of all the Folder and AlbumArtSmall files. Then that settled all the non-stop syncs and it stopped. Today, I happen to look at the Sync Home tab and again I see "99% - a few seconds" and the Activity list still shows the exact same two files as waiting to be synced. THIS IS OVER SEVERAL HOURS AND a 6.13KB and 24.23KB file are not synced over a 10GB ethernet link ??? That is just bad. I restart sync, and now it's "0% - a few seconds". The Peer List now shows my HomeServer twice, once with a check mark and another saying the same 2 files are being sent to HomeServer. So, my feature request is that on the "Active Devices" page when viewing activity, if you hover over the files, it gives you the full path. That way, I can go and delete these two files instead of having to delete some thousands and thousands of same name files. So please add to your test cases syncing music between Android phone(s) and Window(s) machine. You have lots of bugs to be fixed. You also need to retest your upgrade from 2.3.8 to 2.5.6. I thought it was strange that "HOMESERVER" was listed twice on the Windows 10 PC. I restarted btsync on Win10, no change. I login to HomeServer to close and reopen bysync, and I see two icons in the taskbar. Normally, I hover over one and it disappears because it was crashed from before and just not refreshed. In this case, I hover over each icon and see both a 2.3.8 AND a 2.5.6. The in place upgrade from 2.3.8 to 2.5.6 clearly didn't happen correctly! I close the 2.3.8 instance, and Windows 10 shows the HomeServer that was synced is now offline. The one that it still shows 2 files to be uploaded is for the 2.5.6 version. Sync on HomeServer shows no transfers happening and in sync with one peer (should have been two, the QNAP and Win10), I just tried uninstalling 2.3.8 from Control Panel Programs and Features. But it looks like it didn't work. I got a pop up with option to "remove settings" and I left it unchecked and clicked OK. After that, nothing appears to have happened and I still see 2.3.8 listed in the Programs and Features as an installed program. After 5 minutes, I try and tell it to uninstall again, and it says I have to wait for the current one to finish uninstalling. So something went wrong with your uninstall process and its just sitting there doing nothing other than eating up about 15% CPU. This product went very unstable after version 2.3.8. If I knew how to roll back mobile, I would have rolled back everything to 2.3.8. I don't know if you lost some key developers or if you're skipping QA after adding tons of features, but this instability is very noticeable and worries me that I experience worse and worse bugs than I ever did with 2.11 (?) versions. I'm now also concerned for the health of my SSD's, due to this non-stop syncing behaviour. I just upgraded the Win10 and WHS to 2.5.7 from 2.5.6, and the 2 files stuck in the queue are now done and both sides think they are in sync. So this may have been fixed in 2.5.7, though I see no specific release note that applies this bug. Please consider hiring back a QA team. Or else get things stable before adding in a bunch of features and causing more bugs. It went from the occasional bug/annoyance that fixed itself with a restart to frequent SERIOUSLY ANNOYING bugs not fixed by restarting the app. Thanks
  16. Sorry, I didn't see that you replied until today. I took screenshots, saw that there was an update and updated it to latest. It is fixed in 2.5.2.
  17. Steve, That sucks. I thought 2.5.2 was going to be the fix. On my Playon media PC running version Resilio 2.4.4, it would behave similar to uTorrent in that it would start saving a continuous stream of video to a folder within Resilio sync and get a message about the file being locked. When I ran into this the other day, I updated it from 2.4.4 to 2.5.2 and there was an observed difference in the file locking notifications and the file did get transferred when it was finished streaming. I didn't update my uTorrent PC to 2.5.2 from 2.3.8 mostly because I didn't have time, but now that you confirmed this bug isn't truly solved, I'll hold off on upgrading as well. If you do go back to 2.3.8, you will have to setup your sync configuration again. I believe there were instructions to restore a backup database from 2.3.8 or something, but it didn't work for me. "If the exact same task is performed using a manual copy (in Windows Explorer) the file will sync OK." You may not notice unless you are running a program that graphs your transmit/receive bandwidth, but when I would manually copy the file, there would be hundreds of kbps of data trying to resend the file over and over and over... (despite the file existing in both folders, the timestamp is messed on one of them so it thinks it needs to resend) you'd have to view the logs to see it if you didn't notice the constant background traffic. Or did you mean this only happens when using the xcopy script? Not that it matters, but any reason you don't just have utorrent copy the file when its completed? I guess if you copy it to multiple places, but ain't that what Resilio is for?
  18. Getting incompatible browser messages on a compatible browser is ANNOYING and frustrating. I just keep running into more and more bugs instead of less The 2.x version wasn't perfect, but I've had FAR, FAR less issues. Client running browser: Windows 10 Server running resilio: Centos 7 Resilio Version 2.4.5 Chrome version: Version 58.0.3029.96 (64-bit) IE11: 11.0.15063 Error message in Chrome (the same PC and chrome works on the server webGUI just last week!!!): But then IE11 works. Go figure.
  19. Helen, Does that mean a new release is around the corner? Contemplating whether to downgrade additional machines or hold off and see if the problems were fixed in a new 2.4.x. Considering the new issues introduced, figured there'd be an update within 3 months, but could be running into more problems than anticipated preventing getting another update out. Thanks
  20. You don't indicate why this would be a good idea, and I certainly don't see why. Break something supported to do something with no visible benefit. Keep your ssl certs and your bt sync stuff separate. bt sync doesn't need to know a domain name and you don't need that hassle. Just let btsync do its encryption the way they intended.
  21. Helen, Use case: uTorrent running on Windows Home Server 2011. Upon torrent completion, file is copied from a temp dir to a network share on the WHS that is also a sync folder with my main Win10 PC. File may or may not continue to be available for seeding. Whenever I've had this problem, I've used "Unlocker" to check and see what file had a file lock, and it always comes back saying there isn't a lock. However, I know that if I remove the file from uTorrent and restart Resilio, the non-stop notifications about the locked file go away (they don't go away on their own until restarted, so bug exists here). But, the file still never syncs (it's FN annoying to discover this after days of non-syncing). If I close Resilio, copy the file manually to the destination sync folder that wasn't getting the file copied automatically (which ends up changing the timestamp I believe), then I end up with HUNDREDS OF KILOBITS PER SECOND of constant traffic trying to copy the file BACK to the WHS folder. It's trying to overwrite the original file with a copy of itself over and over, due to this locked permissions thing. It's the same dang file! Some really bad error handling logic from what I can see. Glad this is over a local LAN and not using up my bandwidth. Actually, now I wonder if this could explain some unexplained traffic spikes as I also have a Resilio sync across the Internet. I was gone for 3/4 weeks in December and yet my Internet bandwidth was higher than average months. (I didn't investigate because I wasn't near by monthly limit to care enough). Probably wasn't good on the SSD for all the constant log writes. Same thing happened on my PlayOn PC. Video's would record to a folder and be constantly written to for the duration of the stream which may be minutes to an hour or more. This starts endless popup notifications about not being able to get lock (WHS would show endless, but I just tried and got a notification at start of video recording but wasn't continuous on a Win10 PC). Then when the recording finished, the file did not get synced, even if Resilio was restarted. This is broken behaviour that started after 2.3.8. I've reverted to 2.3.8 on the WHS and problem went away. It also automatically fixed all the not-synced files that I didn't manually copy over that Resilio never synced (reverting to 2.3.8 lost all my sync, even when I restored the database file as per a post here, but whatever). The file locking changes added in 2.4.x are buggy and break previous functionality. Please test the very typical use case where a program outputs a file to a sync folder and watch for Resilio to start spamming with the notifications.
  22. Check that "Peers online" shows your peer is in fact online. If its not, exit and restart Resilio. Try restarting Resilio anyways, even if thinks peer is online.
  23. No, the core functionality is the seamless syncing. The number of folders is a feature. NO. Data measuring and capping is way more painful than a 10 folder limit.
  24. Where do you live that developers and testers do not need to make a living? When Logmein Hamachi service got cut down to limited free users, they did it with little to no notice, which pissed off a ton of users. Logmein did it because the alternatives out there are a lot more effort. It might cost more, but for anyone who values their time, the cost difference should be negligible, at least in Logmein (and not Bit Torrent's) eyes. I've tried moving away from Hamachi, but couldn't replace the functionality I depended on with addition labour. So I've renewed twice now on multiple subscriptions. Free users did not make them money before, and they reduced their overhead by shedding tons of free users while converting many free users who actually needed the functionality to paying customers. This is what businesses like doing! Users who use the free service only convert to paying in like 2-5% of the cases. All this bitching is for nothing. The decision is made. People who can afford to pay don't hesitate to pay. People who REALLY need more than 10 folders, REALLY should pay as they are getting a lot more return from the service than someone syncing 1-2 folders. The more folders you are syncing, the more time you are freeing up from manual labour. Personally, I'm at 9 (two of which I'm not really using) folders sync'd with 4 TB of data. How many important folders does Windows think you should have? Docs, music, games, videos, downloads, photos... half dozen or so. This covers the majority of people. Another chunk of users will use something like 10 important folders. But an even lower percentage of people will have 10 critical folders needing sync. This is a much smaller percentage of people. So from Bit Torrent's point of view, they are covering nearly everyone who has typical home usage, and people who have higher work loads, well, pay something in return for all the syncing that goes on. Having gone through the Hamachi thing, I'm somewhat prepared by this these days. You can't make a really useful program and not capitalize on it. Talented developers need to make a living and there needs to be an incentive for ongoing development to make it enticing to continue to use it. What I can applaud Bit Torrent for, is that there is a version 1.4.x that can work indefinitely (at least directly connected without tracker use), rather than the service suddenly stop working and leaving people in the lurch to scramble to alternatives or pay. What I think Bit Torrent should have done, is offer a 50% off deal for existing users at least for the first year. I got a deal from Logmein Hamachi ($19 instead of $29 a year) and they are keeping that for annual renewal, so I've gone from hating them to appreciating the service it provides and determining it isn't worth the effort to move services across 50-60 clients to a cheaper service to save $60-$80 a year. The alternatives are just not even close. Offering the introductory price of $20 would have cut down on a lot of this bitching and getting that "what about loyal users" love. It would make the medicine easier to swallow and keep the users hooked on the bt sync heroin. I think its too late to change the folder policy, but it isn't too late to offer a promotional upgrade price, especially through 1.4 auto update mechanism.
  25. Are you using any VPN (-like) service like LogMeIn Hamachi or Neorouter? Are you using VMware or Virtual box that installed extra nic's to your networking? I am doing home lan2lan sync, so I have turned off the options for relay and tracker and DHT, but was still seeing 200-800Kbps of upload traffic going out as per Du Meter (shows up/download speeds). When I would stop Hamachi, the traffic stopped. If I stopped BT Sync, the traffic stopped. Just now, I upgraded to 1.3, and this problem is no longer present. Since you upgraded to 1.3 and still have issue, you don't have same issue as I did, but my whole point is that having multiple NIC's in the PC might be confusing BTSync. I would suggest taking a capture of traffic using Wireshark, and analyzing how much traffic is going where, and to what port. Also, DU Meter had a netstat like feature that told me all the ports the applications were using, and which hostnames it was talking to. I was able to use Wireshark to tell me where the 400Kbps of traffic was going, and I used DU Meter to tell me that it was ALL going to Hamachi's relay server to relay for 50ish clients I have in Hamachi. So, at first, I was having trouble tracking down traffic from BT Sync, but that confirmed it was traffic going over the Hamachi network, but originating from BT Sync somehow. But fixed now, at least for me