Strange behaviour from HDR-FOX T2

I wonder if anyone can help me? In the last few days my HDR-FOX T2, running v3.13 of the custom firmware has started behaving strangely.

Firstly it's very unresponsive to remote control button presses, and very slow to serve up web pages. Both can take many seconds to be actioned.

Secondly, playback of recordings is very stuttery. It can play for a few minutes OK then it starts stuttering. I get some blank screens and some messages saying "The channel is scrambled or not available", and then a few more frames of the recording, some more blank screen etc etc. This is the same for new recordings and for recordings which have been on there for ages and previously played fine many times.

One thing I noticed recently was that the red banner message about bad sectors, which had previously reached around 160, was back down to 2 earlier this week. Is that a cause for concern? I've attached the disk diagnostics report (disk.pdf) in case it shows anything useful to those who understand it better than I do.

Is anybody able to help me by suggesting where the problem lies (eg would a format of the disk help, do I need a new disk, or is it something more serious?).

I've included as much relevant detail as I can think of but I would be happy to provide screen shots or further information.

Many thanks for any help you can offer.
 

Attachments

  • disk.pdf
    391.5 KB · Views: 16
Good afternoon. The fixdisk has just completed. I've attached a log file with everything it produced. Could you tell me if there's anything in there I need to be concerned about or anything I need to do? Is there anything in there that explains the behaviour I'm seeing? Thank you very much for your help.
 

Attachments

  • fixdisk_log.txt
    6.1 KB · Views: 10
Good afternoon. The fixdisk has just completed. I've attached a log file with everything it produced. Could you tell me if there's anything in there I need to be concerned about or anything I need to do? Is there anything in there that explains the behaviour I'm seeing? Thank you very much for your help.
The fix-disk run has certainly corrected some errors. Could you post the hard drive SMART data as it stands now please.
 
auto.log and monitor.db are both quite frequently accessed files so having bad blocks in them could well slow the system down.
So renaming those two files will prevent further attempts to access the corrupted blocks - the files will automatically be recreated when needed.

You could try the following from a humax command line to attempt to recover the sysmon history from monitor.db
Code:
cd /mod/monitor && mv monitor.db temp.db && sqlite3 temp.db ".clone monitor.db"
 
Last edited:
Or
Code:
cd /mod/monitor && sqlite3 monitor.db ".clone temp.db" && mv temp.db monitor.db
which doesn't leave any old junk lying around.
 
After running fixdisk, I've renamed the auto.log file and I've run the command suggested by MymsMan (both using the webshell CLI). First impressions are that it is much improved. It's much more responsive than it was previously and I've managed to watch some recordings without the stuttering issues I was having (so far!). Thank you all for your help.
 
The increase in the reallocated count isn't a problem but as MymsMan says the pending/offline count being greater than zero is a potential issue. I would suggest that when convenient you run fix-disk again and see if that gets the pending/offline count to zero.
 
I ran the fixdisk again today. All was fine until well into the long check, when it got stuck (Waiting 6458) for over an hour. Then the putty session bombed out and now I can't get back in on putty. The front panel says "FixDisk Init". Any advice on what I should do, please? Thank you.
 
Power off and retry.
If it happens again I am not sure what to suggest - if a sector has a problem the disk firmware should have flagged it and carried on.
 
Thanks. I think it somehow dropped off my network mid-test. Whether this was an issue with the humax or an issue with my network I don't know. What I do know is that I had to reboot my router to get it to rejoin the network. Anyway I'm in again on putty and running fixdisk again...
Out of interest, can I do all this from the CLI interface provided by the webshell package or must it be done through telnet? (Until now I've only used telnet).
 
The second fixdisk run is finished. It found three more bad blocks, but none of them is in use. Log attached (fixdisk_log2.txt).

The 168 has gone up to 212, but no mention of pending and offline now.

1595785332571.png

I've also included the SMART data (diskafterfixdisk2.pdf).

Is it looking healthier now?

Thanks
 

Attachments

  • fixdisk_log2.txt
    8 KB · Views: 6
  • disk_afterfixdisk2.pdf
    558.7 KB · Views: 15
Back
Top