MaZder

Members
  • Posts

    3
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    Mainz, Germany

MaZder's Achievements

New User

New User (1/3)

  1. Hi christian, thank you for the code and your PM. Well, when the btsync service is stopped the disks obviously can go to sleep - but that's not a solution. I actually testet it: stopping the service makes the disks sleep again. BTSync can only work when at least two parties are online, so it is a *must* for btsync to run 24/7 in order to be able to recognize changes in the data of other parties. Peter
  2. Hi all, I guess this not a hot topic, because everybody is happy that "it just syncs" -- and that's all right. I'd be happy with that if this was an issue tracker and I'd knew my change-request would not get lost. But I don't get the feeling, that in forseable future anyone would remember this posting. So besides any clarification on the .SyncID-File I'd be interested in a Issue Tracker to post this change-request. Regards, Peter
  3. Hi Guys! Heads up for such a wonderful sync-technique, it almost feels like finally the 21st century is knocking on the doors. I did set up btsync 1.0.134 ARM version on a Synology DS413j and it works like a charm. There's one issue though: The btsync app reads/writes the .SyncID file every ~5 Seconds which inhibits the harddisks from going to hibernation. This is reported from the hibernation debug log: May 25 20:41:47 kernel: [2959743.330000] [/volume1/data/BTSync/.SyncID] opened by pid 9971 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)] May 25 20:41:52 kernel: [2959748.330000] [/volume1/data/BTSync/.SyncID] opened by pid 9971 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)] May 25 20:41:59 kernel: [2959755.320000] [/volume1/data/BTSync/.SyncID] opened by pid 9971 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)] May 25 20:42:02 kernel: [2959758.330000] [/volume1/data/BTSync/.SyncID] opened by pid 9971 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)] May 25 20:42:04 kernel: [2959760.310000] [/volume1/data/BTSync/.SyncID] opened by pid 9971 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)] May 25 20:42:08 kernel: [2959764.320000] [/volume1/data/BTSync/.SyncID] opened by pid 9971 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)] May 25 20:42:20 kernel: [2959776.320000] [/volume1/data/BTSync/.SyncID] opened by pid 9971 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)] May 25 20:42:23 kernel: [2959779.330000] [/volume1/data/BTSync/.SyncID] opened by pid 9971 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)] May 25 20:42:50 kernel: [2959806.330000] [/volume1/data/BTSync/.SyncID] opened by pid 9971 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)] May 25 20:43:02 kernel: [2959818.330000] [/volume1/data/BTSync/.SyncID] opened by pid 9971 [u:(/usr/local/btsync/bin/btsync), comm:(btsync)] Is there any reason why the app needs to interact with this file so often? Wouldn't it be possible to use the kernel's inotify interface to monitor the file (for read access) or postpone write access until a client connects (and a wakeup is unavoidable)? Not beeing able to go to hibernation greatly increases energy consumption, noise and heat generated by the NAS device. If there's anythin I can help with, just let me know. Regards, Peter