Video Freeze then audio goes then a hard restart is required

A

AntS

New Member
HUMAX FOXSAT HDR

After many years of fautless service about 2 weeks ago my HUMAX started behaving oddly.

It was operating with what was the last officially supplied firmware (from 2012?).
It would work for a while (10-15 minutes) and then when I changed channel it would go to a black screen (displaying the new channel info in the box at the bottom for a few seconds).
The screen remained black, neither the remote or the front panel buttons had any effect and only a power cycle by the mains switch on the rear left would have any effect.
Once power cycled it would work perfectly for another 10-15 minutes before the fault reoccurred in exactly the same way and continued to repair.

I opened the box and checked that the fan was working (I suspected overheating) and that involved pulling the HDD.
The fan was working well (although it is hardly blowing a gale).

After reassembly there was no change in behaviour.

I then wondered if there might be a HDD issue and as the 1TB drive was >50% full I got sidetracked into trying to access the files without doing USB downloads and that led me to the Custom Firmware 4.1.3 upgrade which I did successfully via a USB stick in the front socket.
Having connected the box to my router I then downloaded everything I wanted via the web interface and deleted everything from the HDD.
I then reformatted the HDD via the HUMAX user interface.

On first reconnecting the box to the TV everything seemed better but a different issue is now occurring.

Now after about 10-15 minutes the video freezes. Shortly after that the audio goes and only a power cycle by the mains switch on the rear left has any effect.

Of course I cannot be sure what the reason for the change in the fault behaviour is. It could be:
1) The firmware upgrade
2) The fact that the HDD has been emptied and reformatted

The only reason I can think why a HDD fault would be an issue would be tied in to the fact that the box records "the last two hours" of any channel it is on and if it is struggling to do this then this could ultimately lead to some sort of "buffering" issue (using the term in it's loosest sense) that eventually crashes the box.

I was considering swapping the HDD (respecting the 1 TB limit) and I do have a few spare drives (all bigger than 1TB of course).

I was wondering if anything like this has been seen before and if there's anything else I could try.

I have some engineering experience but software (Filezilla, telnet etc.) is not my speciality so if there's anything simple I can try to rectify the issue.

Finally other than the 1TB limit and a 3 GB/s read/write speed limit is there anything else I should consider in terms of the spec?
I did read something about not buying a PC HDD because error checking slows the write speed down the write speed which causes issues.

Thanks in advance for your help.
 
First thing to do is a fix-disk using the maintenance mode and you'll need telnet . You should have done that rather than reformatting the disk in the first place. See the WebIF documentation> Custom Firmware > Custon Apps (preinstalled) tab.

A >1TB disk needs setting up (formatting and partitioning) via Linux before installing in the -HDR.
See WebIF documentation > FAQs > Upgrading the Hard disk tab
 
Rodders53 said:
First thing to do is a fix-disk using the maintenance mode and you'll need telnet . You should have done that rather than reformatting the disk in the first place. See the WebIF documentation> Custom Firmware > Custon Apps (preinstalled) tab.
--------------------------------------------
--------------------------------------------
Click to expand...
Thanks for the instructions.

Once I realised that WebIF was the browser I quickly found the instructions and got to "Maintenance Mode" via telnet very quickly (open a Windows "cmd" window and telnet the unit's IP address).

The attachment (002) shows the results (I did not intervene at any point) and the issue reported is that the superblock and the physical size of the drives are not the same (in blocks). This took only a few minutes.

I don't believe this has repaired the issue.

I re-ran fix-disk to see if the response was the same (see attachment 003) and the final result was the same (same number of blocks) and again only took a few minutes.

Any further advice would be appreciated.
 

Attachments

  • Maintenance_Mode_002.jpg
    Maintenance_Mode_002.jpg
    98.7 KB · Views: 4
  • Maintenance_Mode_003.jpg
    Maintenance_Mode_003.jpg
    116.1 KB · Views: 4
AntS said:
Once I realised that WebIF was the browser
Click to expand...
Just to clarify: a "browser" is the software running on your computer which enables you to access web pages (any web page). Firefox, Safari, Edge, Internet Explorer, Chrome (etc) are browsers.

What you are accessing the Foxsat by using a browser is a specific web page which provides a user interface to the custom firmware, hence "web interface" abbreviated to WebIF. The WebIF is not a browser – you use a browser to view and interact with the WebIF.

If you're going to use the custom firmware, but don't read up on the terminology, then you're not likely to be understood when explaining a problem nor understand what you're told to solve it.
 
Black Hole said:
Just to clarify: a "browser" is the software running on your computer which enables you to access web pages (any web page). Firefox, Safari, Edge, Internet Explorer, Chrome (etc) are browsers.

What you are accessing the Foxsat by using a browser is a specific web page which provides a user interface to the custom firmware, hence "web interface" abbreviated to WebIF. The WebIF is not a browser – you use a browser to view and interact with the WebIF.

If you're going to use the custom firmware, but don't read up on the terminology, then you're not likely to be understood when explaining a problem nor understand what you're told to solve it.
Click to expand...
Understood - poor use of terminology on my part as I tried to explain that I didn't understand that WebIF was that specific web page.
 
AntS said:
Any further advice would be appreciated.
Click to expand...
You don't know whether the superblock or the partition table is corrupted. Either way, the safest thing to do is to backup your recordings and re-format the disk and reinstall/restore.
Trying to play about with fixing the partition table or the filesystem using the tools manually could result in total loss.
 
prpr said:
You don't know whether the superblock or the partition table is corrupted. Either way, the safest thing to do is to backup your recordings and re-format the disk and reinstall/restore.
Trying to play about with fixing the partition table or the filesystem using the tools manually could result in total loss.
Click to expand...
-----------------------------------------------------------------------------------------------------------------------------------------------
That was what I did originally so the disk is now pretty much empty apart from a short test recording done after it was reformatted (which was done before I tried fix-disk).

If the disk corruption is the cause of the problem then I see only a few options:
1) Reformat the drive in-situ using the unit's format option. This hasn't worked before (pre fix-disk) so is probably unlikely to work,
2) Pull the drive out of the unit and format it (FAT32 I presume) by putting it in an external HDD case. I have a FAT32 format utility on my Windows 10 PC (ridgecrop dot co.uk/index.htm?guiformat.htm).
3) Replace the drive with another 1TB one (if I can find anything suitable).
 
Black Hole said:
One way to confirm whether the HDD is the cause of your problems is to leave it disconnected and see how the unit operates then (without recording or timeshift functionality of course).

---------------------------------
Click to expand...
I wasn't sure that would work - I'll give it a try.
 
AntS said:
Reformat the drive in-situ using the unit's format option. This hasn't worked before (pre fix-disk) so is probably unlikely to work,
Click to expand...
It might be some more Humax stupidity to do with formatting that we see on the T2 models.
Can you run these commands from the Foxsat command prompt and report the output:
Code: 
dumpe2fs -h /dev/hda1|grep -E "Block (size|count)"
dumpe2fs -h /dev/hda2|grep -E "Block (size|count)"
dumpe2fs -h /dev/hda3|grep -E "Block (size|count)"
dumpe2fs -h /dev/hda4|grep -E "Block (size|count)"
fdisk -lu /dev/hda
I'm not sure how changing the disk is going to fix a filesystem problem, presumably as you will just format it the same as the existing disk.
 
prpr said:
It might be some more Humax stupidity to do with formatting that we see on the T2 models.
Can you run these commands from the Foxsat command prompt and report the output:
Code: 
dumpe2fs -h /dev/hda1|grep -E "Block (size|count)"
dumpe2fs -h /dev/hda2|grep -E "Block (size|count)"
dumpe2fs -h /dev/hda3|grep -E "Block (size|count)"
dumpe2fs -h /dev/hda4|grep -E "Block (size|count)"
fdisk -lu /dev/hda
I'm not sure how changing the disk is going to fix a filesystem problem, presumably as you will just format it the same as the existing disk.
Click to expand...
As requested - see attached
 

Attachments

  • dumpe2fs.jpg
    dumpe2fs.jpg
    32.6 KB · Views: 5
  • fdisk_lu.jpg
    fdisk_lu.jpg
    22.5 KB · Views: 5
AntS said:
As requested - see attached
Click to expand...
It all looks consistent, with the exception of the filesystem on /dev/hda3, as you've already shown.
If there really is nothing in the Movie and Video folders that you want, then I would be tempted to just re-format that partition (from Maintenance mode):
Code: 
umount /mnt/hd3
mkfs.ext3 /dev/hda3
I'm not sure whether the Foxsat supports operation with the "-O sparse_super" or "-T largefile" flags on the mkfs.ext3 command. You could try them first and drop them if not. Once it's done, just check with dumpe2fs /dev/hda3|grep -E "Block (size|count)" again.
 
Black Hole said:
Perhaps if there's a hard fault in a critical area.
Click to expand...
A smartctl -a /dev/hda would report on the existing physical state of it (having installed the smartctl package first of course). Unlike the T2, this isn't in the flash.
 
So I pulled the HDD connector out and that has stopped the video freeze/sound loss "crash" so I guess it is safe to conclude it's a hard disk issue that's connected to the block issues that fix-disk has reported.
I'll install and try smartctl and then do the format from Maintenance Mode as suggested.
 
prpr said:
A smartctl -a /dev/hda would report on the existing physical state of it (having installed the smartctl package first of course). Unlike the T2, this isn't in the flash.
Click to expand...
Here are the results of "smartctl" to be read 001, 002, 003 with some overlap.

There are a series of errors (numbered 6389n) as follows:
1713804085182.png
 

Attachments

  • smartctl_003.jpg
    smartctl_003.jpg
    87.2 KB · Views: 3
  • smartctl_002.jpg
    smartctl_002.jpg
    177.4 KB · Views: 3
  • smartctl_001.jpg
    smartctl_001.jpg
    195.4 KB · Views: 2
  • 1713803925789.png
    1713803925789.png
    37.3 KB · Views: 3
You must log in or register to reply here.
Back
Top