kbtombul

I can also try the experimental builds on OSX and Linux(x64).

I was having "Out of Sync" issue with one of my shares, it was working fine until a couple of days ago. I only have one R/W and one encrypted node and I just added some new files to R/W node like I always did. When I checked the logs I noticed the lines below keep repeating in the log of R/W node. [20141214 05:32:53.017] SF[452E] [141F]: Going to sync state with peer [peer ip]:62981[20141214 05:32:53.017] ScheduledTask:SyncState invoked:immediately reason:FinishStateSync - sync not completed[20141214 05:32:53.097] MC[452E] [141F]: generating intial request with root 5FC72698660EA36CE07200AEBC64FCDCCB9DDBDA[20141214 05:32:53.215] API: --> getsyncfolders(discovery=1&t=1418563973210)[20141214 05:32:53.283] SF[452E] [141F]: Received request "id"[20141214 05:32:53.283] SF[452E] [141F]: Got id message from peer [peer name] (102799A00B7C0CCF2109A7B15031C0FB72B7141F) 1.4.103[20141214 05:32:53.283] SF[452E] [141F]: Received request "peers"[20141214 05:32:53.283] SF[452E] [141F]: Received request "root"[20141214 05:32:53.283] MC[452E] [141F]: processing root message, remote hash 0C835821E09CBD93F42AF04B32407BF623EB9B4A, timediff: 0[20141214 05:32:53.283] MC[452E] [141F]: requesting nodes for root[20141214 05:32:53.714] SF[452E] [141F]: Received request "nodes"[20141214 05:32:53.714] MC[452E] [141F]: processing nodes message for /[20141214 05:32:53.714] MC[452E] [141F]: will request nodes for /GTEYJ6PCKK34PTZ75ZVKXTE5WR6BARDX2QOYDQY[20141214 05:32:53.714] MC[452E] [141F]: sending get_nodes message[20141214 05:32:53.922] SF[452E] [141F]: Received request "nodes"[20141214 05:32:53.922] MC[452E] [141F]: processing nodes message for /GTEYJ6PCKK34PTZ75ZVKXTE5WR6BARDX2QOYDQY[20141214 05:32:53.922] MC[452E] [141F]: will request files for /GTEYJ6PCKK34PTZ75ZVKXTE5WR6BARDX2QOYDQY[20141214 05:32:53.922] MC[452E] [141F]: will request nodes for /GTEYJ6PCKK34PTZ75ZVKXTE5WR6BARDX2QOYDQY/4UKXRMQGSKUQRXEJXBQ7XCMTTUGFNGCWF2KVKN4SRRJBQRPOVXTQ[20141214 05:32:53.922] MC[452E] [141F]: will request nodes for /GTEYJ6PCKK34PTZ75ZVKXTE5WR6BARDX2QOYDQY/5QUU3CMTLUIKTC2NRAHZXXDKIRP7TIUMNDNEEEUGLGSTFXQ3EF5A---- REDACTED ----[20141214 05:33:01.270] MC[452E] [141F]: will send file /GTEYJ6PCKK34PTZ75ZVKXTE5WR6BARDX2QOYDQY/RKQEVBVXUV42L3YIS63EVOXG34P6IM5WNDDT4WGR2YMKA3KMFSZQ/JUV3AF6VA24XZHRGNV6FVMDWAA/O6I37AKQ72ETFUCAR6WI4FGPWU[20141214 05:33:01.271] MC[452E] [141F]: Local file [folder1]/[folder2]/[folder3]/[folder4] is newer than remote t:1418539030/1409580159 ot:1019765/737 o:10DB722EA4A96E5B2FDCE0308490D2CC335D453B/10DB722EA4A96E5B2FDCE0308490D2CC335D453B[20141214 05:33:01.271] MC[452E] [141F]: will send file /GTEYJ6PCKK34PTZ75ZVKXTE5WR6BARDX2QOYDQY/T74PJI2SINIPQHS3J62QSC5FXFGDDIV7PWH3NLTMUTZZICQ7KSZQ/RN4TQJDFU2OCFCNXTYVYJWXJ4A/NQOAJBXTAFXEW2LDZVRZUDQXDU[20141214 05:33:01.271] MC[452E] [141F]: Local file [folder1]/[folder5]/[folder6]/[folder7] is newer than remote t:1418364710/1409580129 ot:1019415/441 o:10DB722EA4A96E5B2FDCE0308490D2CC335D453B/10DB722EA4A96E5B2FDCE0308490D2CC335D453B[20141214 05:33:01.271] MC[452E] [141F]: will send file /GTEYJ6PCKK34PTZ75ZVKXTE5WR6BARDX2QOYDQY/UQLH65NIA6PYVEV3YSO5DBF227IQRDB4TV4FGX6GFGOXITDTIQ4Q/BOCZ27GR6WGSPB7EWBIQC3KMMQ/TXF75XD2R5BWDYXDRUEQ4IG5BU[20141214 05:33:01.271] MC[452E] [141F]: Local file [folder1]/[folder5]/[folder6]/[folder7]/[folder8] is newer than remote t:1418364710/1409580129 ot:1019414/456 o:10DB722EA4A96E5B2FDCE0308490D2CC335D453B/10DB722EA4A96E5B2FDCE0308490D2CC335D453B[20141214 05:33:01.271] MC[452E] [141F]: will send file /GTEYJ6PCKK34PTZ75ZVKXTE5WR6BARDX2QOYDQY/UQLH65NIA6PYVEV3YSO5DBF227IQRDB4TV4FGX6GFGOXITDTIQ4Q/BOCZ27GR6WGSPB7EWBIQC3KMMQ/TXF75XD2R5BWDYXDRUEQ4IG5BU/DCADFUS47MILQIS5PFEDPBQW3E[20141214 05:33:01.271] MC[452E] [141F]: Local file [folder1]/[folder5]/[folder6]/[folder7]/[folder8]/[folder9] is newer than remote t:1418364643/1409580129 ot:1019399/474 o:10DB722EA4A96E5B2FDCE0308490D2CC335D453B/10DB722EA4A96E5B2FDCE0308490D2CC335D453B[20141214 05:33:01.271] MC[452E] [141F]: will send file /GTEYJ6PCKK34PTZ75ZVKXTE5WR6BARDX2QOYDQY/UQLH65NIA6PYVEV3YSO5DBF227IQRDB4TV4FGX6GFGOXITDTIQ4Q/BOCZ27GR6WGSPB7EWBIQC3KMMQ/TXF75XD2R5BWDYXDRUEQ4IG5BU/DCADFUS47MILQIS5PFEDPBQW3E/2JRDCERIMWLCRUJGV2WFPHKHZM[20141214 05:33:01.271] MC[452E] [141F]: Local file [folder1]/[folder5]/[folder6]/[folder7]/[folder8]/[folder10] is newer than remote t:1418364710/1409213823 ot:1019413/457 o:10DB722EA4A96E5B2FDCE0308490D2CC335D453B/10DB722EA4A96E5B2FDCE0308490D2CC335D453B[20141214 05:33:01.271] MC[452E] [141F]: will send file /GTEYJ6PCKK34PTZ75ZVKXTE5WR6BARDX2QOYDQY/UQLH65NIA6PYVEV3YSO5DBF227IQRDB4TV4FGX6GFGOXITDTIQ4Q/BOCZ27GR6WGSPB7EWBIQC3KMMQ/TXF75XD2R5BWDYXDRUEQ4IG5BU/DCADFUS47MILQIS5PFEDPBQW3E/G5MDB74BO443LXDKYWE2V7EVWY[20141214 05:33:01.271] MC[452E] [141F]: Local file [folder1]/[folder5]/[folder6]/[folder7]/[folder8]/[folder9]/[folder11] is newer than remote t:1418364643/1409580129 ot:1019398/476 o:10DB722EA4A96E5B2FDCE0308490D2CC335D453B/10DB722EA4A96E5B2FDCE0308490D2CC335D453B[20141214 05:33:01.271] MC[452E] [141F]: will send file /GTEYJ6PCKK34PTZ75ZVKXTE5WR6BARDX2QOYDQY/UQLH65NIA6PYVEV3YSO5DBF227IQRDB4TV4FGX6GFGOXITDTIQ4Q/BOCZ27GR6WGSPB7EWBIQC3KMMQ/TXF75XD2R5BWDYXDRUEQ4IG5BU/DCADFUS47MILQIS5PFEDPBQW3E/2JRDCERIMWLCRUJGV2WFPHKHZM/64LXQEKCKFRC73WF3MFBAESZTE[20141214 05:33:01.272] MC[452E] [141F]: failed to verify signature of remote file [folder1]/[folder5]/[folder6]/[folder7]/[folder8]/[folder10]/[filename].jpg, aborting[20141214 05:33:01.272] SF[452E] [141F]: State sync finished[20141214 05:33:01.297] API: --> getsyncfolders(discovery=1&t=1418563981292)[20141214 05:33:02.307] API: --> getsyncfolders(discovery=1&t=1418563982302)[20141214 05:33:03.285] SF[452E] [141F]: Going to sync state with peer [peer ip]]:62981[20141214 05:33:03.285] ScheduledTask:SyncState invoked:timer reason:FinishStateSync - sync not completed It seems like it keeps aborting and restarting, it never starts sending the new files. Any idea why this might be happening, and how to solve this?

Not really. If a r/w node deletes files and if this changes is synced to other nodes, deleted files are moved to /backup/folder/.sync/Archive folder. By default they will stay there for 30 days, so you can recover what you need. There is also an advanced setting "sync_trash_ttl" that lets you control this duration, if you set it to 0 those files won't be deleted from Archive folder. I have that setting set to 0 on all my devices, unless I need the disk space all of deleted/changed files stay in the Archive folder. When I need more space I just go in there and delete the files that I'm sure I won't need.

You can! Just set it to 0.

Sorry, I have been writing the other post for a while, didn't see your reply. That's a good point, I'm not worried about CPU/Memory consumption though. I keep my (virtual) sdcard folder and camera folder synced to my Mac. I wanted to add a cloud node (Backupsy) in case something happens and I wanted it to be encrypted for obvious reasons. Do you think my problem is caused by a bug in BTSync or the app dying/getting killed because of heavy processing? Also do you have any suggestions on how I can achieve what I want to achieve without using encrypted keys on the device (without copying the content to another folder on my Mac to sync with cloud of course )? ----- I did, but late, the page is not being updated while I write the post. It works for some time and actually syncs some files, but it crashes later, maybe when the memory usage increases or something.

I think no one has any idea what's happening here Anyways, I did some more testing, it doesn't crash when I use regular r/w keys but it crashes all the time when I use r/w keys generated as encrypted. After it crashes the service restarts in the background then crashes again, then again, until the OS says that's enough.

I didn't notice this problem until today so it might have been introduced with the latest version, or even the OS update. I don't keep BTSync running most of the time so I don't know when it started. I had two backup folders setup, one of them was sdcard root folder and the other one was Camera folder. I wanted to add an encrypted node for these folders. I generated an new key to use with the root folder. I removed the root folder that was setup as a backup folder, added it again with the new r/w key. Then I noticed that it crashes. I checked the logcat, found the lines below but nothing else, and I can't access the dump file because my phone is not rooted. Here is some info: Motorola Droid MaxxAndroid: 4.4.4System Version: 23.3.24.obake-maxx_verizon.Verizon.en.USBuild number: SU5-24BTSync: 1.4.56.0 (tried both play store version and apk)E/UTERRORONOES(19612): Dump path: /data/data/com.bittorrent.sync/files/.sync//5761bf64-bf7e-3df0-06159e7f-65204c26.dmpI/UTERRORONOES(19612): BTSync Core error: coreCrashCallback() called successfully.I/ActivityManager( 914): Process com.bittorrent.sync (pid 19612) has died.I/WindowState( 914): WIN DEATH: Window{4387c908 u0 com.bittorrent.sync/com.bittorrent.sync.ui.activity.MainActivity}W/ActivityManager( 914): Scheduling restart of crashed service com.bittorrent.sync/.service.CoreService in 256000msW/ActivityManager( 914): Force removing ActivityRecord{433a0688 u0 com.bittorrent.sync/.ui.activity.MainActivity t40}: app died, no saved state

+1 to this.

Thanks GreatMarko, but I meant the old Transfers tab. Random result from Google Images Search: http://techreport.com/r.x/2013q1/bittorrent-sync.jpg

I used to be able to see the files that are being transferred at the moment, however I can't seem to find it on 1.4. Is it missing in this version or is it just me?

It is a limitation of the operating system. On iOS 7, applications can run at most 3 minutes (was 10 on iOS 6) after they are sent to background without requiring some special permissions. As you have already noticed, if an app is using location in the background it can run indefinitely, I work for Rove so I know it from experience. It's the same for the apps that plays sound and that have VoIP capabilities, like Skype. There is also background fetch feature that can restart the apps in the background from time to time, however the timing is not consistent and the duration is still limited, 30 seconds I think, or maybe 3 minutes. Again if the app starts using location during this period, it can run indefinitely. I believe Apple wouldn't approve an app to have these special permissions without having corresponding features. Background fetch could be enough for syncing newly added photos for example, but than again, there are things like the indexing files, discovering peers that could take much of this limited time the app has in the background.

Here is my wishlist: 1. Make the app window behave like a normal application window. I can't switch to it using Cmd+Tab or Dock or from the menu bar icon with only one click. 2. Disable notifications for some folders. I am backing up the -virtual- sdcard folder on my Galaxy Nexus, I don't need to know that every cache file in every application data folder is downloaded. 3. Show an info window when I double click to an item in Folders list, instead of opening it in Finder. Maybe something similar to the Torrent Inspector in Transmission. Also move the current action to the context menu. 4. Let me close the app window with Cmd+W, I don't remember the latest 1.1 but it is not working on 1.2.41 for sure. Edit: 5. UserVoice or something similar, so that we don't need to go through ~40 pages of wishlist