herzi

Are you familiar w/ GNU/Linux systems? Invoking that command should absolutely be _not_ necessary. Ever. It also shouldn't be invoked from inside the application. The application should just work out of the box.

I tried, but as long as the alignment issue isn't solved, there is no way to upgrade from 1.1.48 on the ARM machine.

I tested v1.2.68, it still yields alignment errors.

BTW, at least with 1.1.48, the log files seem to be misleading. The date specifier should be 20131031 (as there is no 31st of September).

Hi, I tried to use BTSync to synchronize some big audio files (hours of uncompressed PCM => several GBs) from my old Mac Mini (quite slow) to my NAS system. However, it doesn't work: Some investigations led me to guess an explanation for this: 1. The client on the Mac realizes there is a new file, it will do these two things 1.a. Start generating meta data 1.b. Announce the existence of the file across the network 2. The client on the NAS receives the announcement and will try to get the metadata for the file. 3. The client on the Mac does not have the metadata yet, and rejects the metadata request. 4. The client on the NAS will retry this several times. 5. The client on the NAS gives up and blocks the Mac client. 6. The client on the Mac eventually generates the metadata, but the client on the NAS is not willing to talk to the Mac client anymore. Is this a valid scenario? Can I help you investigating with this? The client on the NAS is v1.1.48 (because of the alignment problems in more recent versions). On the Mac, I have tested both the most recent version and v1.1.48. From the NAS' log file: [20130931 10:21:03.910] Loading config file version 1.1.48[20130931 10:21:03.976] Loaded folder /home/user/Folder[20130931 10:21:04.004] Loaded folder /home/user/Folder-incoming[20130931 10:21:07.963] BAN peer: Responsible for 'file.wav' metadata not being loaded![20130931 10:21:07.963] Banned 192.168.2.111:25444 until forever