Sysmon slows HDR down so replay drops out.

I was having a problem tonight where every recording I played back was freezing every 30 secs ish so I opened up Sysmon to have a look at the CPU usage and it didn't show the graph. I re installed it using the diagnostics page which made no difference. I then removed it and the recording I was playing back started to play back correctly. I next installed it and the playback was freezing again and the webif interface for sysmon still didn't display the graph.

I've had to remove it for now.

Are there any setup or configuration files that could be causing the problem?


Staff member
This sounds like you have a bad or suspect sector in your hard disk in the sysmon database file. I had exactly the same symptoms recently. Once the suspect sector is written to again, the disk firmware will either decide that it's fine now or it will reallocate it, but for now reads are failing. What size disk do you have?

I'll post commands to try later to confirm the cause; the easiest fix is to remove the sysmon database and let the system create a new one.

Ezra Pound

Well-Known Member
I think that uninstalling the Sysmon utility will only remove the executable files, to remove the database enter the following from Telnet :-

rm /var/lib/humaxtv/monitor.db
I've renamed the monitor directory to monitor-old and re-installed sysmon which regenerated the monitor folder. I then tried to copy the old monitor.db file from the monitor-old directory to the new monitor directory, calling it monitor-old.db I got a read error just like af123 suggested.

Could it be that the db file gets corrupt if it is being written to as the HDR is told to reboot by the webif?

Edit:. After 30 Mins I now have a new db file with data and a graph showing.

Just need AF123 to tell me how to check my disk now :)

Ezra Pound

Well-Known Member
I don't have a monitor file in that directory, I do however have one in /mod/monitor/
I found an old file at /var/lib/humaxtv/monitor.db dated 7th May, and another file at /mod/monitor/monitor.db dated with current time and date. So I can only assume the location of this file has changed, anyway you found the correct one


Staff member
Could it be that the db file gets corrupt if it is being written to as the HDR is told to reboot by the webif?
It shouldn't be - this is something that is triggered by the firmware on the disk itself. It loses confidence in a particular sector and returns read errors on it. Once something else is written to that address it will either decide that it's fine now or choose to reallocate it to one of its spare sectors.

Just need AF123 to tell me how to check my disk now :)
Install the smartmontools package and post the output of
humax# smartctl -A /dev/sda
You're specifically interested in the Reallocated Sector Count, Current Pending Sector and Offline Uncorrectable fields.

I found an old file at /var/lib/humaxtv/monitor.db dated 7th May
That isn't related to sysmon. Not sure what that would be as I don't have one on my box. It might be something that's created by the Humax firmware.

Ezra Pound

Well-Known Member
That isn't related to sysmon. Not sure what that would be as I don't have one on my box. It might be something that's created by the Humax firmware.
It's my fault I'm afraid, I've just remembered why it's there. The Web-If Database Browser points to /var/lib/humaxtv, so I copied the monitor.db file to this location in order to view it using the Web-If :oops:
OK here is the output.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
1 Raw_Read_Error_Rate 0x000f 098 076 006 Pre-fail Always - 23126611
3 Spin_Up_Time 0x0003 097 097 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 097 097 020 Old_age Always - 3470
5 Reallocated_Sector_Ct 0x0033 098 098 036 Pre-fail Always - 99
7 Seek_Error_Rate 0x000f 078 060 030 Pre-fail Always - 76577613
9 Power_On_Hours 0x0032 097 097 000 Old_age Always - 3251
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 099 099 020 Old_age Always - 1735
184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0
187 Reported_Uncorrect 0x0032 001 001 000 Old_age Always - 5160
188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0
189 High_Fly_Writes 0x003a 098 098 000 Old_age Always - 2
190 Airflow_Temperature_Cel 0x0022 053 045 045 Old_age Always In_the_past 47 (Min/Max 41/47)
194 Temperature_Celsius 0x0022 047 055 000 Old_age Always - 47 (0 21 0 0)
195 Hardware_ECC_Recovered 0x001a 046 037 000 Old_age Always - 23126611
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 1
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 1
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0


Staff member
Having both Current Pending Sector and Offline Uncorrectable set to 1 is a clear sign that you have a sector that the disk isn't happy with. What is odd with these disks is that this one thing can cause transport problems and hangs when reading content from other parts of the disk.

I think your reallocated sector count is 99 which is higher than I'd expect - nothing to worry about yet though.

If you write zeros over the old copy of the sysmon database then it should force the disk to re-evaluate that sector, something like:
humax# dd if=/dev/zero of=/mod/monitor-old/monitor.db bs=1m
would do it. If you've already deleted the file then it's safest to just leave it - eventually something will try to write to the affected sector. It would be possible to identify the address of the sector and use the filesystem debugger to map a file to it, but it's definitely safer just to leave it.

btw, if you do a Humax hard disk check through the system menu you'll probably get a fail at the moment although I don't agree with that diagnosis!
OK I've run that, although it didn't like the bs=1m. I used 1k then tried 1000k. Neither finished but I assume the file was written with something. I've now deleted the old directory. Only time will tell if it worked.

Thanks Af123.

Black Hole

May contain traces of nut
Knee-jerk reflex - adding or removing a package frequently needs a reboot before it takes effect, so I'm in the habit of always doing one. You might have enough understanding to know when a reboot is or is not strictly necessary, but I don't and I guess that goes for quite a few.


Staff member
I think it's fair to say that enough of the popular packages do require a reboot to become fully active that it's a reasonable default view to take and a reboot should always be done prior to posting questions just in case!

For instance: redring, undelete, ir, custom-portal, portal-xtra1, auto-unprotect, disable-dso, disable-ota, ...


Well-Known Member
It would be nice if this could be communicated to the user somehow, or at least documented somewhere slightly easier to find than buried in a message board.
Perhaps even just adding a note to the relevant package's description?