Cerberus wrote:1) nope would defeat object of serviio if it went to sleep as it would then not be availible for devices on the network.
2) No thats just linux being silly.
Hi all.
I'd like to revisit the topic of serviio interferring with MBL standby. Standby is an attractive feature of this device. If no HDD activity happens for set time, the drive is spun down. For regular home use the box is in standby for long periods of time. Addition of serviio makes the HDD spin 24/7.
I found why this happens and how to prevent it. It so happened that the periodic idle file IO can be redirected to in-RAM filesystems /var/log or /tmp. Maybe the author can address this in a way cleaner than my hack and make serviio a 'better citizen' on low power devices.
For starters, automatic library rescan has to be disabled. Redirect serviio log to /var/log (duh!). This can be done by modifying config/log4j.xml. Change value of "File" parameter to "/var/log/serviio.log".
Standby feature is implemented by /usr/local/sbin/monitorio.sh. When run with ''debug' argument, this script shows detailed trace of process file IO. For serviio java process it displayed frequent accesses of files in ~/.java/.userPrefs. This directory is used by Java user preferences API java.util.prefs. Quick google search found that this API automatically and periodically saves preference key-value pairs to disk...
In addition serviio periodically wrote small ~/.dir file. Its content matches the saved preference in ~/.java/.userPrefs/com/nto/info/prefs.xml.
Periodic save of preferences appeared to be the only culprit so I just went ahead, created /var/log/serviio_prefs directory and two symlinks:
~/.java/.userPrefs -> /var/log/serviio_prefs
~/.dir -> /var/log/serviio_prefs/.dir
The device started entering standby mode again.
Note that the content of /var/log is lost each reboot so the creation of the links should be added to the /etc/init.d/serviio script.
I have no idea about the purpose of ~/.dir file and com.nto.info preferences. Placing them in RAM filesystem and recreating after reboot did not seem to create any problems though.
This issue was introduced between versions 0.6.2 and 1.3.1. 0.6.2 did not prevent standby as it was.
Cheers and thanks for creating the best media server out there.