Latest 1.2.82 Build

[ade_m]

Build 1.2.73

 

Two PCs running, and initially all looked ok.

 

I sync a Thunderbird profile from PC A to PC B, purely for backup (TB isn't installed on PC .  Thousands of little files basically.  Everything was synced ok.

 

For some reason after a reboot today of PC A, PC A tells me its syncing files (downloading) from PC B.

PC B says nothing in the history, but under Devices shows an Upload of hundreds of megs and I can see on network stats that PC B is transmitting files back to PC A.

 

I'll see if I can send both hosts logs in.

[vadimt]

OK, thanks a lot!

[vadimt]

 

 

 

 

 

And what about the opposite situation: when file gets deleted from server1. Does this deletion propagate to server2 as well? What about other files which happen to exist in the synced directory on server2 (read-only) node but not on the originating (server1) node? Will it delete everything it finds there which doesn't have its counterpart on server1?

 

 

If you delete file on server1 this file will be deleted on server2 too. Files that exist on server2 only are not indexed by BTSync on server2 at all and these files will not be included in sync process.

Thanks!

[Zbig]

If you delete file on server1 this file will be deleted on server2 too. Files that exist on server2 only are not indexed by BTSync on server2 at all and these files will not be included in sync process.

Thanks!

 

Thank you for clarification.

[ade_m]

Rebooted the PC again (PC A), and its off again 'Finished syncing file....' thousands of times.  Estimated a PC B -> PC-A download of 3.5gb of file size.  Let me know if you need more logs as this seems repeatable after a reboot.

[vadimt]

Did you send logs to syncapp@bittorrent.com?

Thanks!

[ade_m]

vadimt,

 

I enabled debug logs and used Send Feedback - is that the same thing?

[unixunderground]

Why can't BTSync just integrate an option to allow it to run an auto-update whenever a new build gets released?

 

I have it installed on 5 different linux servers in different locations, as part of my "dropbox-like" implementation, and it's a giant pain in the ass to log in via SSH, stop the service, wget the new file , replace it, and restart the service 5 times in a row every single time a new build comes out....

 

And since now new builds are coming up every week or so, the pain-in-the-ass-factor is greatly increased too.

[GreatMarko]

Why can't BTSync just integrate an option to allow it to run an auto-update whenever a new build gets released?

 

I have it installed on 5 different linux servers in different locations, as part of my "dropbox-like" implementation, and it's a giant pain in the ass to log in via SSH, stop the service, wget the new file , replace it, and restart the service 5 times in a row every single time a new build comes out....

 

And since now new builds are coming up every week or so, the pain-in-the-ass-factor is greatly increased too.

 

I agree with you, however, as Sync is currently still in a "beta" phase, and new test builds are released frequently, not every beta build is pushed via auto-update - This will change once Sync leaves beta and the auto-update feature is fully "turned on".

 

I also agree that once auto-update is fully "turned on", that it would be great if Sync could auto-update itself without any user interaction - this makes a lot of sense on head-less servers!

 

Personally, the way I hope to see this working in the future would be that if you're sharing a folder between a number of devices, one of which is running a newer version of Sync, then as part of the data transfer, that newer version of Sync will automatically and securely propagate and install on all the devices you're sharing between - to ensure that all your devices will always be running identical versions of Sync!

[r0x0r]

Indexing fails between Mac/Mavericks and PC/Windows 7. The culprit is the band !!!

Below's an excerpt from the log file. Will be glad to provide any additional information.

 

Any quick workaround for this?

 

 

[2013-11-23 19:15:23.068] LoadTorrent: requesting to load file !!!\!!! - Louden Up Now\01 !!! - When The Going Gets Tough, The Tough Get Karazzee.mp3 which is modified on disk (cur:1355689332 stored:1384882932 size1:9557693 size2:9557693 hasInfo:0) - rejecting until file info is updated

[2013-11-23 19:15:23.069] LoadTorrent: requesting to load file !!!\!!! - Louden Up Now\02 !!! - Pardon My Freedom.mp3 which is modified on disk (cur:1355689332 stored:1384882932 size1:8873684 size2:8873684 hasInfo:0) - rejecting until file info is updated

[2013-11-23 19:15:23.069] LoadTorrent: requesting to load file !!!\!!! - Louden Up Now\03 !!! - Dear Can.mp3 which is modified on disk (cur:1355689332 stored:1384882932 size1:6983182 size2:6983182 hasInfo:0) - rejecting until file info is updated

[2013-11-23 19:15:23.069] LoadTorrent: requesting to load file !!!\!!! - Louden Up Now\04 !!! - King's Weed.mp3 which is modified on disk (cur:1355689333 stored:1384882933 size1:1776448 size2:1776448 hasInfo:0) - rejecting until file info is updated

[2013-11-23 19:15:23.069] LoadTorrent: requesting to load file !!!\!!! - Louden Up Now\05 !!! - Hello  Is This Thing On .mp3 which is modified on disk (cur:1355689333 stored:1384882933 size1:11459025 size2:11459025 hasInfo:0) - rejecting until file info is updated

[19feet]

Bittorrent still keeps indexing for a very long time (for about 150 GB data) every time I startup the PC. Ubuntu One works much better with this amount of data.

Is there a plan to modify bittorrent sync for better indexing?

[r0x0r]

Resolved my problems by running chkdsk on my hdd. It fixed some errors and now indexing is going on smoothly.

[GreatMarko]

Bittorrent still keeps indexing for a very long time (for about 150 GB data) every time I startup the PC. Ubuntu One works much better with this amount of data.

Is there a plan to modify bittorrent sync for better indexing?

 

It's important to let Sync finish indexing your folders before powering off your device. If indexing is incomplete/interrupted, whilst this won't do any harm, it will mean that the next time you start your computer (and Sync), Sync will attempt to re-index the folder(s) again.

 

Once you've allowed Sync to fully index your 150GB folder, it shouldn't need to re-index it again upon subsequent runs.

[daishi4u]

It's important to let Sync finish indexing your folders before powering off your device. If indexing is incomplete/interrupted, whilst this won't do any harm, it will mean that the next time you start your computer (and Sync), Sync will attempt to re-index the folder(s) again.

Once you've allowed Sync to fully index your 150GB folder, it shouldn't need to re-index it again upon subsequent runs.

I disagree. My computer indexes with every start and yes I let it fully index

Sent from my SCH-S738C using Tapatalk

[GreatMarko]

I disagree. My computer indexes with every start and yes I let it fully index

Sent from my SCH-S738C using Tapatalk

 

Yes, I should have been more clear - I was referring to a folder's initial indexing. Obviously, Sync rescans the folder each time you start sync in order to detect any changes to files that were made whilst Sync wasn't running.

 

But these subsequent "rescans" should be very quick in comparison to initial folder indexing, as the entire index isn't rebuilt from scratched each time, just "refreshed".

 

Sent from my computer using my keyboard

[daishi4u]

Yes, I should have been more clear - I was referring to a folder's initial indexing. Obviously, Sync rescans the folder each time you start sync in order to detect any changes to files that were made whilst Sync wasn't running.

But these subsequent "rescans" should be very quick in comparison to initial folder indexing, as the entire index isn't rebuilt from scratched each time, just "refreshed".

Sent from my computer using my keyboard

It's quicker, but still takes at least a half hour each time

Sent from my SCH-S738C using Tapatalk

[ade_m]

I'd have to agree with daishi4u

 

After  reboot, the client sits there adding files that are alrady synced. On mine it means its sat there for an hour+

[krtaylor]

I'd have to agree with daishi4u

 

After  reboot, the client sits there adding files that are alrady synced. On mine it means its sat there for an hour+

 

Sort of.  I've found mine to look like that's what it's doing, and the log shows all the files as being "synced", but checking the transfer rate and traffic, it isn't actually transmitting all the files - in my case that would take a day or two.  I think what it's doing is just transmitting the hashcode for each file to make sure they haven't changed, which I guess is a good practice after a reboot since you never know what might have changed while you weren't paying attention.

[daishi4u]

But hard drive activity goes nuts for about half an hour on each boot and takes forever to boot the computer now. Wasn't till version 1.2 that this started. I've looked at the task manager and it's definitely btsync. Just decided to never turn the computer off till this issue is taken care of haha

Sent from my SCH-S738C using Tapatalk

[19feet]

It's important to let Sync finish indexing your folders before powering off your device. If indexing is incomplete/interrupted, whilst this won't do any harm, it will mean that the next time you start your computer (and Sync), Sync will attempt to re-index the folder(s) again.

 

Once you've allowed Sync to fully index your 150GB folder, it shouldn't need to re-index it again upon subsequent runs.

 

I wasn't referring to a folder's initial indexing. I was referring to the "rescans". They need a long time every time I startup the PCs (Linux Ubuntu 12.04 64bit, 32bit, Linux Ubuntu 13.10 64bit).

[daishi4u]

That's what I was referring to as well...

Sent from my SCH-S738C using Tapatalk

[tuxpoldo]

The problem on x86 GEODE CPUs is still not solved with 1.2.82. Any Idea when the bugfix will be released? I know that there is a solution upcoming...

[vadimt]

Indexing fails between Mac/Mavericks and PC/Windows 7. The culprit is the band !!!

Below's an excerpt from the log file. Will be glad to provide any additional information.

 

Any quick workaround for this?

 

 

[2013-11-23 19:15:23.068] LoadTorrent: requesting to load file !!!\!!! - Louden Up Now\01 !!! - When The Going Gets Tough, The Tough Get Karazzee.mp3 which is modified on disk (cur:1355689332 stored:1384882932 size1:9557693 size2:9557693 hasInfo:0) - rejecting until file info is updated

[2013-11-23 19:15:23.069] LoadTorrent: requesting to load file !!!\!!! - Louden Up Now\02 !!! - Pardon My Freedom.mp3 which is modified on disk (cur:1355689332 stored:1384882932 size1:8873684 size2:8873684 hasInfo:0) - rejecting until file info is updated

[2013-11-23 19:15:23.069] LoadTorrent: requesting to load file !!!\!!! - Louden Up Now\03 !!! - Dear Can.mp3 which is modified on disk (cur:1355689332 stored:1384882932 size1:6983182 size2:6983182 hasInfo:0) - rejecting until file info is updated

[2013-11-23 19:15:23.069] LoadTorrent: requesting to load file !!!\!!! - Louden Up Now\04 !!! - King's Weed.mp3 which is modified on disk (cur:1355689333 stored:1384882933 size1:1776448 size2:1776448 hasInfo:0) - rejecting until file info is updated

[2013-11-23 19:15:23.069] LoadTorrent: requesting to load file !!!\!!! - Louden Up Now\05 !!! - Hello  Is This Thing On .mp3 which is modified on disk (cur:1355689333 stored:1384882933 size1:11459025 size2:11459025 hasInfo:0) - rejecting until file info is updated

 

Please try the latest 1.2.82 version http://syncapp.bittorrent.com/1.2.82/. This issue should be fixed there. Thanks!

[bwainscott]

@vadimt: Will Android 1.2.14 ever hit the Google Play store?  I have 1.2.12 installed, and the Play store has the "What's New" that includes 1.2.14, but insists I'm up to date.  I don't know if it is possible, but it LOOKS like they updated the comments without actually updating the executable?  I know I can install directly from the apk file linked on the first page, but was waiting to use the Play store and it has been a couple of days now.

 

Thanks.

[vadimt]

We will turn on full autoupdate on Google Play soon.

Thanks!