Sysmon slows HDR down so replay drops out.

D

David_Brown_UK

Member
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?
 
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.
 
I think that uninstalling the Sysmon utility will only remove the executable files, to remove the database enter the following from Telnet :-

Code: 
rm /var/lib/humaxtv/monitor.db
 
Ezra Pound said:
I think that uninstalling the Sysmon utility will only remove the executable files, to remove the database enter the following from Telnet :-

Code: 
rm /var/lib/humaxtv/monitor.db
Click to expand...
I don't have a monitor file in that directory, I do however have one in /mod/monitor/
 
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 :)
 
David_Brown_UK said:
I don't have a monitor file in that directory, I do however have one in /mod/monitor/
Click to expand...

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
 
David_Brown_UK said:
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?
Click to expand...

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 :)
Click to expand...

Install the smartmontools package and post the output of
Code: 
humax# smartctl -A /dev/sda

You're specifically interested in the Reallocated Sector Count, Current Pending Sector and Offline Uncorrectable fields.

Ezra Pound said:
I found an old file at /var/lib/humaxtv/monitor.db dated 7th May
Click to expand...
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.
 
af123 said:
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.
Click to expand...
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.

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
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
 
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:
Code: 
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.
 
I have had sysmon disabled (and other things) for a couple of weeks, and my HDR is behaving much better.
 
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.
 
I think "frequently" is a bit of an over-statement. Most things do NOT require a reboot. Linux != Windows.
 
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, ...
 
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?
 
You must log in or register to reply here.
Back
Top