mv2010

[GonzoTEH]

Unable to find help with HP... I have 4 HP Medial Vault 2010's work great of our offices... the issue is ther seems be a bug in the firmware since Jan 1 2016.  The time clock and DHCP lisc renawal, both change to the year 2032 and as a result the MV starts to run slow.. the only solution, is the rename the device as which resets network connections.. but then the same issue occurs the following day.

Any suggestions would be greatly appreciated or perhaps if there was any remote change HP would address this firmware issue.

Thanks.

[gear2th]

I've run into the same thing.  This resulted in the media server process ms-mips hogging the CPU, even though I turned off media serving on all folders - I had to kill the ms-mips process, ultimately by adding a startup script to do so.  I found that the hardware clock (hwclock) will incorrectly set the year to 2032 if copying from the system time starting in 2016 (hwclock -s).

The system time is quickly corrected after boot when the time is read from an ntp server.  However, I believe that after 24 hours, the system reads the hardware clock into the system time again, restoring the error.  What I'm trying now is that I set in nvram sync_to_hwclock_interval to 24000000 instead of 24,  so it won't happen for about 2700 years.

This appears to be working after a couple of days, though I would have thought that "sync TO hwclock" meant going in the other direction, that is TO the system clock.  But it seems okay and I see that each day (I also changed it so that the ntp server is read daily instead of every 3 days by changing ntp_interval to 24 from 72) it also writes it to hwclock.  HWCLOCK is then in sync with the system clock (other than the 16-year error) and they start to drift apart, until synced again the next day, and so far the system date's year has stayed at 2016.

I've experimented with turning on the media server and found it no longer hogging the CPU, but I turned it off again.

[GonzoTEH]

that sounds amazing.... so how can I implement your solution?  Also wonder why rename the device name gets all back operating normally.

[gear2th]

In case you don't already know this, for general info. such as setting up startup scripts and writing to NVRAM see

http://k0lee.com/hpmediavault/  .  Also the Yahoo group http://groups.yahoo.com/hpmediavault can be useful, but is low on recent posts; only I have posted about this issue there so far.

My main solution is to telnet to the mediavault and execute the following commands:

ntpclient -h pool.ntp.org -s

date

    Check that the date and time look correct.  The above two commands should not be necessary unless you don't want to reboot after finishing.  Then enter the following:

nvram set sync_to_hwclock_interval=24000000

nvram set ntp_interval=24

nvram commit

   After entering these commands, the issue should go away.  Rebooting is optional; if you do reboot wait a couple of minutes before doing anything CPU-intensive as the year will be 2032 again for a minute or so.  You can also use rebooting to verify you entered things correctly, such as by entering

nvram show| grep interval

   In the first set of commands, use the first time server under system settings-clock settings if it is different than pool.ntp.org.

If you want to stop the media server, include the following in /shares/Volume1/startup.sh or a script called from /shares/Volume1/startup.sh:

#!/bin/sh
cd /shares/Volume1/_DLNAMediaServer_/server
sleep 40
./server stop

You can also execute these commands manually or just kill the ms-mips process if you don't want to wait for a reboot.  In either case, you should also disable media sharing on all folders.

If you DO use media streaming and the system gets slow, hitting the "reset media streaming" button should fix it, at least for a while, but I'm hoping this won't be necessary after the clock fix.

I haven't renamed my system.  If renaming it reboots it, I think that would fix the system for a day.  If it doesn't reboot, renaming might cause it to get the time from the ntp server immediately, which would also fix it for a day.  Or maybe it causes media streaming to reset, which would also fix it for a day.

[gear2th]

no message.

[GonzoTEH]

Thank you for the reply.... So after telneting in and entering thes commands they will hold indenfinitly between reboots, power cycles etc?

Also when you say stop the server... what do you mean... streaming media?  We just use the MV for data file and access files so I think I don't need the media server... no?

[gear2th]

The command "nvram commit" will make the nvram changes persist between reboots.  I can't guarantee that the clock won't cause some kind of problem later; I've only been doing this a few days.

Since you are not using the media server, you could add the startup script I mention to stop it from running, but this may not be necessary.

Lee Devilin's (k0lee) MediaVault site has good general info. on telnetting, making nvram changes, adding startup scripts and lots of other stuff.

[GonzoTEH]

Thanks I'll give your solution a try and give it some time... I apprecaite your help.